Legacy System Migration to the Cloud: How to Move Without Downtime or Data Loss

Signs Your System Is Holding the Business Back

It is usually easier to identify a modernization candidate by its symptoms than by the age of its codebase. Warning signs include several of the following occurring at the same time:

• The technology stack is no longer supported. The operating system, programming language or database no longer receives security updates, while incompatible dependencies make an upgrade difficult.
• Maintenance costs are rising disproportionately. Every change requires more engineering time, only a small number of people understand the code, and tests are missing or no longer reliable.
• The system has reached its scalability limit. It has outgrown the capacity of a single server but cannot scale horizontally because critical state is stored in process memory.
• Security and compliance risks are increasing. Known vulnerabilities remain unpatched, encryption is missing, or the system cannot meet regulatory audit requirements.

If three or four of these symptoms apply, the system is likely accumulating both technical and financial debt—and postponing action will eventually make the problem more expensive to solve.

When Cloud Migration Makes Sense—and When On-Premises Is the Better Option

Cloud migration is usually justified when workloads are uneven, with peaks caused by reporting periods, seasonality or marketing campaigns. It can also make sense when the business needs to scale quickly without purchasing additional hardware, when an existing infrastructure estate is due for renewal, or when the required level of resilience would be difficult to build and maintain in-house.

The opposite can also be true. A stable system with predictable demand that has been running unchanged for years may cost more in the cloud, particularly if it is simply moved as-is without taking advantage of managed services or other cloud capabilities.

The same applies to workloads with highly specific hardware requirements or situations where data must remain under direct organizational control for legal or operational reasons.

A hybrid model is often a practical compromise. Sensitive core systems remain on-premises, while scalable components and additional capacity move to the cloud.

The 7 Rs: From Rehost and Replatform to Refactor

The seven approaches cover the full spectrum, from making almost no changes to fundamentally redesigning the application:

Rehost (Lift and Shift)

Moving a virtual machine or application with minimal or no changes. This is usually the fastest option, but it may leave cloud capabilities underused and produce higher-than-expected costs if the original infrastructure is inefficient.

Relocate

Moving an entire platform environment without repackaging individual workloads. For example, a VMware vSphere environment can be moved with minimal changes to the virtual machines themselves. This approach minimizes downtime and rework.

Replatform (Lift and Reshape)

Moving the application while making targeted optimizations. A self-managed database running on a VM might become a managed database service, while file storage moves to object storage. The application code changes as little as possible, but some operational work is removed.

Refactor (Re-architect)

Fundamentally redesigning the application for cloud-native operation. This may involve breaking a monolith into microservices, containerizing workloads and using Kubernetes for orchestration. It is the most expensive and time-consuming option, but it offers the greatest potential for scalability and resilience.

Repurchase (Drop and Shop)

Replacing a custom-built system with a SaaS product when the functionality is relatively standard, such as email, CRM or accounting.

Retire

Decommissioning systems that are no longer needed. An infrastructure audit often reveals that 10–20% of services can simply be switched off.

Retain

Making a deliberate decision to leave the system where it is, for example because of data requirements or because the application is already close to retirement.

One of the biggest migration traps for legacy systems is choosing Rehost by default. An old monolith can often be moved over a weekend, but in the cloud it may continue consuming resources just as inefficiently—except that every unnecessary gigabyte of memory now generates a recurring monthly cost.

For heavily used systems, Replatform is therefore often the more sensible choice. For applications that will remain central to the business for years to come, Refactor may provide a stronger long-term foundation.

Migration Strategy and Downtime: What You Trade for Speed

Migration strategy should be evaluated against one of the project's main constraints from the start: how much downtime can the business tolerate?

The deeper the modernization work, the more preparation is required upfront—but the smoother the final cutover can be. Conversely, a fast Rehost using a cold migration usually involves the most noticeable outage.

The pattern is simple: cutover downtime is inversely related to the amount of work invested in replication and parallel operation beforehand.

A cold Rehost saves preparation time but pays for that speed with a visible maintenance window. Refactoring and well-designed replication move most of the work before the cutover, leaving only a short maintenance window—or, in some cases, a traffic switch that users barely notice.

Blue-Green, Canary and Gradual Traffic Switching

A blue-green deployment uses two parallel environments. The "blue" environment is the current production system, while the "green" environment is the new cloud deployment.

Users continue working with blue while green is populated with data, tested under load and validated functionally. The cutover is performed by changing routing on the load balancer or updating DNS records. For users, the switch can take only seconds.

If something goes wrong, traffic is routed back to the blue environment. Rollback can be as fast as the original switch.

A canary deployment is a more gradual approach. Only a small percentage of traffic—perhaps 1–5%—is initially sent to the new system. If everything works as expected, the share can increase to 25%, 50% and eventually 100%.

At each stage, teams monitor metrics such as error rates, including HTTP 5xx responses, response latency, database load and business metrics such as conversion rates. If the metrics remain within acceptable thresholds, more traffic is moved. If they do not, the deployment is rolled back before the issue affects the entire user base.

When using DNS for the cutover, remember that DNS records are cached by providers and clients. In the days before migration, the TTL should therefore be reduced to around 30–60 seconds.

Gradual traffic switching at the load-balancer level does not have this limitation and is generally preferable to DNS-based switching for business-critical systems.

For companies moving a fleet of virtual machines from an international cloud platform to infrastructure in Russia, Cloud4U offers a migration service based on VMware vCloud Availability. The service replicates virtual machines between a customer's VMware vSphere or Cloud Director environment and the provider's cloud. It supports both hot and cold migration as well as migration in both directions.

Because replicas can be kept up to date before the final cutover, the switch can be completed with minimal downtime and without data loss.

Maintenance Windows, API Backward Compatibility and Rollback Planning

Even with well-designed replication, there is usually a short maintenance window for final synchronization and cutover. It should be scheduled during periods of lowest demand, communicated in advance and reduced as much as possible. With hot migration, this is typically measured in minutes rather than hours.

API backward compatibility is another challenge. If services are migrated gradually, old and new versions may operate simultaneously for a period of time.

Changes must therefore remain compatible. New fields should be introduced as optional, while old fields and interfaces should follow a defined deprecation process. The expand-contract pattern makes it possible to change data schemas and application contracts without breaking existing consumers.

A rollback plan should also be treated as part of the migration design, not as an emergency document prepared at the last minute. Before cutover, define:

• Success criteria — measurable thresholds such as an error rate below X%, p95 latency below Y milliseconds and zero data discrepancies.
• Rollback criteria — the metric values that trigger a rollback rather than waiting for the problem to resolve itself.
• The point of no return — the moment after which rollback is no longer possible, for example when the old database starts receiving new records without reverse synchronization.
• A decision owner — the person authorized to order a rollback based on the agreed metrics, without losing valuable minutes to approvals.

Replication, CDC and Dual Write: Keeping Data in Sync

A traditional "stop, copy and restart" database migration is only possible when the business can tolerate downtime for the entire copying process. For large databases, this is rarely acceptable, so continuous synchronization is typically required.

Logical replication is a built-in database capability available in systems such as PostgreSQL and Microsoft SQL Server. Changes are transferred from the primary database to a replica in near real time. An initial snapshot is copied first, after which the replica catches up using database logs and remains synchronized until cutover.

CDC (Change Data Capture) uses a separate process to read changes from the database transaction log and transfer them to the target system. It is useful when source and target databases are different technologies or when the change stream needs additional processing during migration.

Dual write means that, for a limited period, the application writes to both the old and new databases. This provides additional control, but a failed write to one database can create inconsistencies. For this reason, dual write should be used with consistency checks and only for a carefully controlled period.

In practice, the most common approach for large databases is initial snapshot plus log-based replication. It minimizes both downtime and the risk of data divergence.

Dual write is usually reserved for scenarios where the cutover needs the additional flexibility of keeping both systems capable of receiving writes temporarily.

Data Integrity Checks and Traffic Cost Control

Moving the data is not enough—you also need to prove that nothing was lost.

A minimum validation set should include comparing record counts for key tables, checking checksums or hashes for samples and, where necessary, entire critical tables, validating referential integrity, and manually reviewing selected business-critical records.

These checks should be automated and performed before cutover against the replica rather than against the production workload.

Another less obvious factor is data egress pricing. When data leaves an international cloud platform, the source provider may charge for every gigabyte transferred out.

Consider a company migrating a database and file storage with a combined volume of 50 TB:

These figures are illustrative. The actual cost will depend on the provider's pricing, region and the real volume of changes during the migration.

Costs can be reduced by compressing data before transfer, moving only current and necessary datasets, excluding systems that are being retired, and choosing a destination provider that does not charge for inbound traffic or internal data transfers.

For a migration into a Russian cloud environment, the main cost often comes from exporting data from the original international platform rather than receiving it at the destination.

Migration Project Checklist: From Dependency Audit to Legacy System Retirement

1. Audit and inventory. Map systems, dependencies, integrations and data flows. This is also the stage for identifying Retire candidates and hidden dependencies that could break neighboring services.
2. Choose a strategy for each system. Assign the appropriate 7 Rs approach to every application based on business criticality, acceptable downtime and budget.
3. Assess data and traffic. Calculate database volumes, the rate of data change, migration costs and potential data egress charges.
4. Run a pilot. Migrate one non-critical system end to end, from replication to traffic cutover. A pilot exposes problems in the migration methodology before they affect business-critical workloads.
5. Perform load testing. Test the new environment against realistic and peak demand profiles. Skipping this step is a common reason why an apparently successful migration fails during its first hours of production traffic.
6. Complete final synchronization and cutover. Use the planned maintenance window, switch traffic using blue-green or canary techniques, and monitor the agreed metrics.
7. Stabilize and monitor. Run the new system under close observation for several days or weeks while keeping the rollback plan available.
8. Retire the old environment. Only after stability has been confirmed should the old system be shut down, data archived and resources released. Moving too quickly at this stage removes your safety net.

Russian Data Localization Requirements and 1C Migration

For companies operating in Russia, migration planning may include regulatory requirements in addition to technical considerations.

Where a system processes the personal data of Russian citizens, organizations need to take Russian personal data localization requirements into account, including Federal Law No. 152-FZ. This can affect where relevant databases and processing infrastructure are located and should be assessed as part of the migration design.

As a result, moving workloads from international cloud platforms to infrastructure located in Russia can be both a technical and a compliance project. Payment card environments may also involve PCI DSS requirements, while certain industries have additional information security obligations.

For international companies entering the Russian market, it is particularly important to assess these requirements before the migration architecture is finalized rather than treating them as a post-deployment compliance task.

Hosting infrastructure in a Tier III-level data center in Russia can help address both infrastructure availability requirements and data localization considerations. When personal data is involved, providers should be able to document the relevant security and compliance measures, allowing customers to include this evidence in their own compliance processes.

The same careful planning is required for specialized business applications, including 1C, which remains widely used by Russian companies. Migrating such systems without disrupting business operations requires particular attention to application dependencies, database synchronization and the cutover process.