Cloud Migration Strategy: How to Plan an Enterprise Cloud Migration

A cloud migration strategy is the plan that decides how each application and data set moves to the cloud, in what order, and under which security and operating controls. It combines a per-workload approach, such as rehosting, replatforming or refactoring, with a sequence of migration waves, a target landing zone and a cutover plan the operations team can actually run.

Most migrations do not fail on the move itself. They slip because a dependency surfaces late, the target environment is not ready for production traffic, or a cutover has no tested way back. This guide explains the 7 Rs, walks through a step-by-step cloud migration plan, gives a checklist for each phase and covers the risks worth managing before the first workload moves.

What Is a Cloud Migration Strategy?

A cloud migration strategy answers three questions for every workload in scope: which migration approach it will use, when it will move, and what has to be true in the target environment before it does. It sits between the business case and the technical runbooks. The business case says why the organization is moving. The strategy turns that into decisions per application. The runbooks describe how each move is executed on the day.

A useful strategy is portfolio-wide rather than application-by-application. Enterprises rarely migrate a single system; they move hundreds of servers, databases and integrations that depend on each other. Treating the migration as a program, with an inventory, grouping by dependency, a shared target platform and a wave plan, is what keeps sequencing stable as new facts appear.

It is also different from a cloud adoption strategy. Adoption covers the whole journey, including governance, skills and new cloud-native development. Microsoft's Cloud Adoption Framework (opens in new tab) separates it into Strategy, Plan, Ready, Migrate, Modernize, Cloud-native, Govern, Secure and Manage. Migration is one part of that journey, and it goes better when the Ready work, meaning the landing zone, is done first.

What Are the 7 Rs of Cloud Migration?

The most widely used way to choose an approach per workload is the "7 Rs." In its AWS Prescriptive Guidance on migration strategies (opens in new tab), AWS lists seven: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Each workload gets exactly one, and the mix across the portfolio shapes the timeline and the skills the program needs.

That last point matters. AWS notes that rehost, replatform, relocate and retire are the common strategies for large migrations, and recommends modernizing applications after they have moved rather than during the migration. Teams that try to refactor everything at once usually turn a migration into a multi-year rebuild. For a closer look at the simplest option, see our guide to cloud lift and shift.

How Do You Build a Cloud Migration Plan?

A cloud migration plan turns the strategy into a sequence the organization can execute. The steps below follow the order Sphere uses on migration programs: assess, build the foundation, migrate in waves, then optimize.

1. Define outcomes and constraints. Agree what the migration must achieve, such as exiting a data center by a fixed date, improving resilience or enabling new services, and list the constraints: compliance, data residency, maintenance windows and systems that cannot move yet.
2. Inventory the portfolio and map dependencies. Record every application, database and integration with its owner, criticality and the systems it talks to. Dependencies discovered late are the most common cause of resequencing.
3. Assign a strategy to each workload. Apply the 7 Rs to every item in the inventory. Retire and retain decisions shrink the scope early; rehost and replatform carry most of the volume.
4. Build the landing zone first. Set up identity, network controls, logging, policies and the operating model in the target environment, and get security and operations to sign off before production workloads arrive.
5. Group workloads into waves. Bundle applications that depend on each other, start with lower-risk waves to prove the process, and attach a cutover runbook, validation steps and a rollback plan to each wave.
6. Migrate, validate and stabilize. Execute each wave, reconcile data, run test gates, and keep a stabilization period with named owners and operating hours before the next wave starts.
7. Optimize and modernize after the move. Tune sizing and performance, retire what is no longer needed, and plan modernization work, such as refactoring, as a separate backlog once workloads are running in the cloud.

Data platforms deserve their own plan inside the program, because databases need reconciliation and controlled cutovers rather than a simple copy. Our article on planning a data warehouse migration to the cloud covers that track in more detail.

What Should a Cloud Migration Checklist Include?

A checklist keeps every wave honest. The items below are the minimum we would expect a team to confirm at each stage.

Before migration

• Every workload in scope has an owner, a criticality rating and an assigned migration strategy.
• Dependencies between applications, databases and external services are mapped and reflected in wave groupings.
• The landing zone is built, documented and approved by security and operations.
• Compliance and data residency requirements are confirmed for each data set.
• Success criteria are defined per wave: performance targets, acceptable downtime and validation checks.

During cutover

• The runbook has been rehearsed, with named people for each step and a decision point for go or rollback.
• Data is reconciled between source and target before traffic switches.
• Monitoring and alerting are live in the target environment before users arrive.
• Business stakeholders know the maintenance window and how issues will be reported.

After migration

• The stabilization period has clear owners and operating hours.
• Source systems are decommissioned on a schedule, not left running indefinitely.
• Sizing, performance and security posture are reviewed against the success criteria.
• Modernization candidates are recorded in a backlog for later waves.

What Are the Most Common Cloud Migration Risks?

The risks below come up in almost every enterprise program. None of them is exotic, and each has a planning answer.

• Hidden dependencies. An integration nobody documented surfaces mid-wave and forces emergency resequencing. Dependency mapping during assessment, using both discovery tooling and interviews with system owners, is the fix.
• Landing zone gaps. Workloads arrive before identity, network rules and logging are settled, and teams patch controls under pressure. Treat the landing zone as a deliverable with its own sign-off.
• Cutover uncertainty. A downtime window without a rehearsed runbook, validation steps and a rollback path turns a routine move into an incident.
• Data integrity. Large databases need reconciliation between source and target, not just a successful copy job.
• Unclear operating ownership. If nobody owns monitoring, patching and incident response in the new environment, problems surface as user complaints.
• Refactoring too much, too early. Mixing large-scale redesign with migration multiplies risk. Move first, then modernize, unless an application truly cannot run as-is.

Security deserves explicit attention in the plan rather than a review at the end. Our overview of cloud cybersecurity covers the controls that matter once workloads run outside the data center.

How Long Does a Cloud Migration Take?

Duration depends on portfolio size, the strategy mix and how many dependencies tie systems together. A rehost-heavy program moves faster than one with many replatform or refactor decisions, and data platforms usually set the pace. What can be predicted early is the assessment: Sphere's migration assessments run two to three weeks and produce the scope, inventory, risks, target architecture and wave plan the rest of the timeline is built on.

Two Sphere projects show how scoping shapes delivery. In one, a client migrated a custom solution with two terabytes of Oracle databases to Azure, moving analytics workloads to Azure Synapse and transactional workloads to Azure SQL Managed Instance, with Azure Data Factory keeping the two synchronized; the custom cloud migration case study has the details. In another, a multinational company closing its data centers moved a multi-tier .NET application to Azure within a planned maintenance window, keeping its dependencies on remaining on-premise services intact, as described in the data center exit case study.

Should You Use Cloud Migration Services or Migrate In-House?

An internal team can run a migration well when it already operates the target cloud, has capacity beyond day-to-day operations and is moving a limited set of well-documented systems. Outside help tends to pay off when the portfolio is large, when several platforms move at once, such as VMware estates, databases and applications, or when the team has not yet built a production landing zone.

When you evaluate a partner, ask to see a sample wave plan and cutover runbook, how they map dependencies, who signs off the landing zone, and how they hand operations back to your team. Sphere's infrastructure migration services run migrations as a program, with delivery pods that include cloud architects, migration and data engineers, security engineering, QA automation and a cutover lead. Broader platform work sits with our cloud and infrastructure practice, and DevOps and platform engineering covers the pipelines and operations that keep workloads healthy after they land. If several applications need deeper modernization, our legacy system modernization framework helps decide what to move first and what to rebuild later.

Frequently Asked Questions