Cloud Migration Strategy: 7 Rs, Landing Zones, Waves and Cutover Planning

Cloud migration succeeds when it is managed as a business and operating-model change, not simply as a transfer of servers. The target platform changes identity, networking, security, cost, deployment and service ownership. A workload that starts successfully in the cloud can still be a poor migration if it is difficult to operate, unexpectedly expensive or dependent on an on-premises component nobody documented.

A strong migration strategy connects four layers: the reason for moving, the disposition of each workload, the governed cloud foundation and an executable wave and cutover plan. These layers should be decided with evidence and refined as the organization learns.

This framework applies across AWS, Azure and Google Cloud. Provider migration tools differ, but the management questions around business value, dependencies, risk and readiness remain consistent.

Begin with outcomes and constraints

Define why the organization is migrating and how success will be measured. Data-center exit, resilience, global reach, product speed, security improvement and cost flexibility lead to different priorities. A deadline without an outcome encourages teams to rehost everything, defer modernization and discover operating problems after the source environment is gone.

Translate the business case into measurable conditions. Examples include closing a facility by a fixed date, meeting a recovery objective, reducing deployment lead time, enabling a new geography or replacing unsupported technology. Record constraints such as contractual commitments, data residency, software licensing, maintenance windows, skills and regulatory approval.

Create a value hypothesis for each workload group. The hypothesis should state what improves, the investment required and when the benefit can be observed. It gives leaders a basis for deciding whether to migrate, modernize, replace or retire.

Discover the portfolio and map dependencies

An inventory of virtual machines is not an application portfolio. Build workload records that include business owner, technical owner, users, criticality, data classification, architecture, infrastructure, software lifecycle, traffic, recovery objectives, operating cost and known debt.

Dependency discovery deserves particular attention. Capture databases, identity providers, file shares, message systems, DNS, certificates, third-party endpoints, batch schedules, network flows and operational tools. Automated discovery provides evidence, but workshops with application and business owners explain why the connections exist and what failure means.

Classify dependencies by criticality and latency sensitivity. Some components must migrate together. Others can operate across environments temporarily if connectivity, security and performance are tested. Minimize the period of split operation because temporary integration often becomes a fragile permanent architecture.

Use confidence levels in the inventory. Unknown ownership or unverified dependency data is itself migration risk. Do not hide uncertainty behind a completeness percentage.

Select a disposition using the 7 Rs

AWS Prescriptive Guidance describes seven common migration strategies. The labels help organize a portfolio, but they are decisions rather than maturity levels. Refactoring is not automatically better than rehosting, and retaining a system can be rational when migration value is weak.

Record the evidence, owner and confidence behind each disposition. Include licensing, end-of-support dates, dependency complexity, data gravity, expected cloud cost, operational capability and product roadmap. Revisit the decision after early-wave learning.

Avoid turning the 7 Rs exercise into a spreadsheet classification performed by a central team. Application and business owners should accept the consequence. For example, repurchase affects business process and data ownership, not only infrastructure.

Build the landing zone before production migration

A landing zone is the governed foundation into which workloads are deployed. It establishes how the organization manages resource hierarchy, identity, networking, security, logging, policy, billing and automation. AWS commonly uses a multi-account foundation, Azure uses management groups and subscriptions, and Google Cloud uses organizations, folders and projects.

The landing zone should define:

Build the foundation as code where practical. Versioned modules, policy tests and peer review make the environment repeatable and reduce manual drift. Separate organization-wide controls from workload infrastructure so teams can change at the right scope.

Do not wait for a theoretically complete enterprise platform. Establish the minimum production foundation, validate it with representative workloads and expand it through evidence. Conversely, do not move production systems into an improvised account and promise to retrofit identity and network boundaries later.

Design migration waves around dependencies and learning

A migration wave is a coordinated group of applications or components that move within a planning window. Google Cloud and Microsoft guidance both emphasize discovery, dependencies and workload grouping before wave execution. AWS Prescriptive Guidance similarly connects portfolio rationalization with wave planning.

Start with workloads that are low enough in risk to protect the business but representative enough to test the migration system. Moving only trivial servers can create false confidence. An early wave should exercise identity, network, data, monitoring, deployment, support and financial controls.

Group tightly connected components together. Sequence shared services before dependents where appropriate. Confirm that application, infrastructure, security, business and support teams are available during preparation and cutover.

A useful wave plan includes target disposition, architecture, dependency group, landing-zone requirements, data method, test plan, downtime tolerance, cutover window, rollback boundary, owner and acceptance criteria. Include time for remediation and learning between waves.

Standardize repeatable work through runbooks and automation, but preserve workload-specific judgement. A migration factory should reduce coordination and tooling variance. It should not force every database, legacy protocol and critical service through an identical procedure.

Treat data migration as an independent workstream

Data often determines cutover duration and rollback feasibility. Profile volume, change rate, consistency requirements, retention, encryption, transfer bandwidth and source-system constraints. Select offline transfer, bulk copy, continuous replication, dual write or another method from those conditions.

Define authoritative ownership at each stage. During replication, identify which system accepts writes and how conflicts are prevented. Validate row counts, checksums, business totals and application behavior rather than assuming a completed transfer means correct data.

Near-zero downtime approaches generally require continuous replication and a short final synchronization window. They reduce service interruption but increase architecture and operational complexity. Microsoft guidance recommends using near-zero downtime methods for critical systems with strict service commitments and planned downtime where the business can tolerate it.

Rollback becomes difficult after new writes begin in the target. Set a point after which fallback requires forward data reconciliation rather than simple traffic reversal. Business owners should understand that boundary before cutover.

Create a cutover runbook that can be rehearsed

A cutover runbook converts the migration design into time-ordered actions. Every step should have an owner, expected duration, prerequisite, validation and failure response. Include change freeze, final backup, replication check, configuration, DNS or traffic switch, application validation, business acceptance, monitoring and communication.

Define go or no-go criteria before the migration window. Examples include replication lag, unresolved test defects, support coverage, rollback readiness and platform health. The person authorized to make the decision should be named.

Rollback criteria must be observable. "Rollback if there are problems" creates debate during an incident. State thresholds for customer errors, latency, data inconsistency, security control failure or elapsed cutover time. Specify the latest point at which rollback remains technically safe.

Rehearse the runbook in a production-like environment. A tabletop review finds coordination gaps. A technical rehearsal measures transfer, deployment and validation time. For critical systems, test failure paths as well as the happy path.

Communication should be part of the runbook. Stakeholders need clear status, expected impact, decision points and escalation channels. The migration team should not improvise customer or executive updates while diagnosing a technical issue.

Prove operational readiness before declaring success

Migration completion is not the moment traffic reaches the cloud. The receiving team must be able to operate the workload. Confirm monitoring, SLOs, alert routing, runbooks, backup restore, capacity, security operations, support access, cost ownership and incident response.

Use a defined hypercare period with enhanced observation and rapid access to migration specialists. Track defects, performance, spend and support demand. Set exit criteria so hypercare does not become an indefinite substitute for normal ownership.

Decommission source resources only after the data, audit, rollback and business-retention conditions are satisfied. Forgotten infrastructure can preserve cost, attack surface and licensing obligations. Update inventories, contracts, monitoring and disaster recovery documentation.

The DevOps and SRE operating model provides a framework for the delivery and reliability capabilities required after migration.

Manage migration economics throughout execution

Initial business cases often underestimate parallel-run cost, data transfer, licensing, support tiers, observability, security tooling and the labor required to modernize operations. Build a total-cost model that includes migration execution, temporary duplication and target steady state.

Establish cost allocation before the first production wave. Track each wave against forecast and explain variance. Delay long-term commitments until usage is stable enough to support them. A rushed commitment can preserve the economics of an oversized rehosted estate.

Measure benefit realization, not only migrated server count. Useful measures include retired applications, data-center cost removed, deployment lead time, recovery-test performance, incident rate, unit cost and time to provision a compliant environment.

A disciplined migration sequence

The first phase establishes outcomes, portfolio ownership, discovery and the business case. It also identifies workloads that should not migrate.

The second phase creates the landing zone, connectivity, security and delivery controls. Representative pilots validate both platform and operating assumptions.

The third phase plans and executes dependency-based waves. Each wave produces evidence that improves estimates, templates and runbooks for the next.

The final phase stabilizes operations, realizes commitments carefully, decommissions source systems and measures whether the original business outcomes were achieved.

CloudForge provides cloud migration consulting across AWS, Azure and Google Cloud, from discovery and landing-zone design through wave planning and cutover. Provider-specific resources include the Azure migration checklist and Google Cloud migration strategy.

Sources

1. AWS detailed portfolio discovery and the 7 Rs
2. AWS migration wave planning
3. AWS application migration process
4. Microsoft Cloud Adoption Framework migration planning
5. Microsoft Cloud Adoption Framework migration execution
6. Google Cloud Migration Center planning overview