The Migration Imperative

Legacy systems are not a problem you can ignore indefinitely. The on-premise server running your core business application is aging. The vendor who built it may no longer exist. The single engineer who understands the codebase is a key-person risk. And every month you delay migration, the gap between your current architecture and a modern, scalable cloud infrastructure widens.

But migration carries real risk. The system you are replacing works. It processes orders, manages customer data, generates invoices, and supports daily operations. Any disruption to that system disrupts your business. The challenge is not whether to migrate — it is how to migrate without breaking what already works.

This article describes the methodology we use for zero-downtime cloud migration — a six-phase approach that moves legacy systems to the cloud progressively, with rollback capability at every stage and no single point of failure in the transition.

Why Lift-and-Shift Is Usually Wrong

The simplest migration strategy is lift-and-shift: take the existing application as-is and move it to a cloud virtual machine. It is fast, requires minimal code changes, and preserves the existing architecture exactly.

It is also usually the wrong choice. Lift-and-shift moves your legacy problems to more expensive infrastructure without solving any of them. You still have the same monolithic architecture, the same scaling limitations, and the same maintenance burden — but now you are also paying cloud hosting premiums for a system that was not designed to take advantage of cloud capabilities.

Genuine cloud migration means rearchitecting for the cloud: breaking monoliths into services, replacing file-based storage with managed databases, implementing auto-scaling, using cloud-native services for authentication, queuing, and caching. This delivers the actual benefits of cloud computing — elasticity, resilience, reduced operational overhead — rather than simply changing where the same old code runs.

The Strangler Fig Pattern: Migration Without the Big Bang

The strangler fig pattern is the foundation of zero-downtime migration. Named after the tropical fig that grows around a host tree and gradually replaces it, this pattern wraps the legacy system with new cloud-based services that incrementally take over its responsibilities.

The process works as follows:

Place a routing layer in front of the legacy system. All traffic flows through this layer — initially, 100% of traffic is routed to the legacy system unchanged. The routing layer is invisible to users and to the legacy system.
Build the first cloud service. Select one function of the legacy system — ideally a self-contained module with clear inputs and outputs — and rebuild it as a cloud-native service.
Route traffic for that function to the new service. The routing layer directs requests for the migrated function to the cloud service while everything else continues going to the legacy system.
Repeat. Migrate functions one at a time. Each migration is independent, testable, and reversible. If a new service has problems, route traffic back to the legacy system for that function while you fix it.
Decommission. When all functions have been migrated and verified, the legacy system handles zero traffic and can be decommissioned.

This pattern eliminates the single biggest risk in migration: the big-bang cutover where everything must work perfectly on day one or the entire migration fails.

Phase 1: Discovery and Assessment (Weeks 1-3)

Before any migration work begins, we need a complete understanding of what the legacy system does — not just what it was designed to do, but what it actually does today, including undocumented features, edge cases, and integrations that nobody remembers setting up.

Discovery involves:

System mapping: Documenting every function, integration, data flow, and dependency. This frequently reveals connections that stakeholders were not aware of.
Data inventory: Cataloguing all data stores — databases, file systems, configuration files, local caches — their sizes, structures, and relationships.
Traffic analysis: Understanding usage patterns, peak loads, and performance baselines. These become the acceptance criteria for the migrated system.
Risk assessment: Identifying the highest-risk components (typically those with the most integrations or the most complex business logic) and the lowest-risk components (typically stateless utility functions).

The output is a migration plan that sequences the work from lowest risk to highest risk, with clear milestones and rollback procedures at each stage.

Phase 2: Foundation Infrastructure (Weeks 3-5)

Before migrating any application code, we establish the cloud foundation: networking, security groups, IAM policies, monitoring, logging, CI/CD pipelines, and the routing layer that will manage the gradual traffic shift.

This infrastructure is defined as code (Terraform, CloudFormation, or Pulumi) so it is reproducible, version-controlled, and auditable. We also establish parallel monitoring — the same metrics tracked on the legacy system are tracked on the cloud infrastructure so performance can be compared directly.

Phase 3: Data Migration Strategy (Weeks 4-7)

Data migration is the most complex and highest-risk element of any cloud migration. The challenge is not moving data from one location to another — it is keeping data synchronised between the legacy system and the cloud while both are operational during the transition period.

We use one of three patterns depending on the situation:

Change Data Capture (CDC): A CDC pipeline captures every change to the legacy database and replicates it to the cloud database in near-real-time. This is the preferred approach for systems where the legacy database supports CDC (most modern relational databases do).
Dual-write: The application writes to both the legacy and cloud databases simultaneously. This requires code changes in the application layer but works when the legacy database does not support CDC.
Periodic sync with reconciliation: For systems with lower data freshness requirements, a periodic batch sync keeps the cloud database updated, with automated reconciliation to detect and resolve discrepancies.

During the migration period, the legacy database remains the source of truth. The cloud database is a replica that is verified for accuracy before any traffic is directed to cloud services that depend on it.

Phase 4: Incremental Service Migration (Weeks 6-16)

This is the core of the migration — progressively moving functionality from the legacy system to cloud-native services. Each migration cycle follows the same pattern:

Build the cloud service and deploy it alongside the legacy system
Run both systems in parallel, comparing outputs to verify correctness
Route a small percentage of traffic (typically 5-10%) to the cloud service
Monitor error rates, latency, and data accuracy
Gradually increase traffic to 100% over days or weeks
Deactivate the legacy function once the cloud service is handling all traffic successfully

The parallel running phase is critical. By sending the same inputs to both systems and comparing outputs, we verify that the cloud service behaves identically to the legacy system before any user-facing traffic depends on it. Discrepancies are investigated and resolved before the traffic shift begins.

Phase 5: Validation and Optimisation (Weeks 14-18)

Once all functions are running on cloud infrastructure, the validation phase ensures the complete system performs at or above the legacy system's baseline. This includes load testing at peak traffic levels, failover testing to verify resilience, and security penetration testing on the new infrastructure.

This phase also includes cloud-specific optimisation: right-sizing compute instances, configuring auto-scaling policies, implementing cost alerts, and tuning database performance for cloud-native access patterns.

Phase 6: Decommissioning (Weeks 16-20)

The legacy system is decommissioned only after the cloud system has operated successfully in production for a defined stability period — typically 4-6 weeks with zero rollbacks. Even after decommissioning, we maintain legacy data backups and documentation for a minimum of 12 months.

When NOT to Migrate

Not every legacy system should be migrated to the cloud. Migration is not the right choice when:

The system is nearing end of life: If the business function the system supports is being retired within 12-18 months, the migration investment will not pay back.
Regulatory constraints prohibit cloud hosting: Some industries have data sovereignty requirements that genuinely preclude cloud hosting (though this is increasingly rare with regional cloud availability zones).
The system has no scaling or reliability problems: If the legacy system is stable, performant, and adequately supported, migration for its own sake is not justified.

Cost Estimation Framework

Cloud migration costs vary significantly based on complexity, but a realistic framework for budgeting includes: discovery and planning (10-15% of total budget), infrastructure setup (10-15%), data migration (15-25%), application migration (30-40%), and testing and optimisation (15-20%). For a medium-complexity legacy system, total migration typically costs £80,000-£250,000 and takes 16-24 weeks.

The ROI calculation should account for reduced infrastructure costs (typically 20-40% savings on hosting), reduced operational overhead (no physical server maintenance), improved scalability (pay for what you use rather than provisioning for peak), and reduced key-person risk (cloud infrastructure is documented and reproducible).

If you have a legacy system that needs to move to the cloud and want a realistic assessment of scope, timeline, and cost, book a free migration assessment. We will review your current system, identify the highest-risk components, and provide a phased migration plan with clear milestones and budget estimates.

How to Migrate Legacy Systems to the Cloud Without Downtime