Most enterprises have settled the question of whether to migrate to the cloud. IDC expects public cloud spending to pass $1 trillion in 2026 and to double by 2029, and Gartner forecasts infrastructure-as-a-service spending of $292 billion this year, up 31%. The open question is how to migrate without the waste that follows most programs. Flexera’s 2026 State of the Cloud report, a survey of more than 750 cloud decision makers, found that 85% say managing cloud costs is their top challenge, wasted cloud spend has risen to 29%, and understanding application dependencies is the biggest barrier to migration, cited by 54%.
A cloud migration strategy is a method, with phases, exit gates and owners, and that is what this guide sets out. The 7 Rs are covered first, because every migration assigns one to each application, and then the rest of the article is the six-phase plan from business case to governed operation, with the gate that has to be passed before each phase is funded.
Table of contents
Key takeaways
- The 7 Rs (retire, retain, rehost, relocate, repurchase, replatform, refactor) are the options per application. AWS’s guidance for large migrations is to refactor only when the other options won’t work, and to modernize after the move.
- The method has six phases: strategy and business case, discover and assess, mobilize, plan the waves, migrate and cut over, optimize and govern. Each ends with a gate.
- Dependency discovery is the gate most programs fail. In Kyndryl’s 2026 survey of 2,000 leaders, only 9% said they fully understand their applications’ dependencies, and 54% in Flexera’s survey called dependencies the biggest migration barrier.
- Cost control is built in from phase one, with tagging and cost allocation in the landing zone and a FinOps practice that now has to cover AI spend: 98% of practitioners in the 2026 State of FinOps survey manage AI costs, up from 63% a year earlier.
- AI tooling compresses discovery, code conversion and test generation. AWS reports 7 billion lines of code processed and an estimated 2 million hours saved by its agentic migration service in its first year. The gates still belong to people.
The 7 Rs of cloud migration in one table
The 7 Rs are the seven things that can happen to an application in a migration. AWS’s Prescriptive Guidance, which builds on the five options Gartner identified in 2011, defines them as follows.
| Strategy | What it means | When it fits |
|---|---|---|
| Retire | Decommission the application and shut down its servers | No business value, idle, or no inbound connections in 90 days |
| Retain | Keep it where it is, for now | Data residency rules, high risk, recent upgrades, or platforms that need their own plan |
| Rehost | Move it without changing it (lift and shift) | Large portfolios, data center exits, tight timelines |
| Relocate | Move whole virtualized environments to the same platform in the cloud | Fastest route for VMware estates |
| Repurchase | Replace it with a different product, usually SaaS | Commodity capabilities such as email, CRM or HR |
| Replatform | Move with limited optimization, such as a managed database | Cloud benefits without rewriting code |
| Refactor | Change the architecture to use cloud-native features | The application must scale, release or integrate in ways its design can’t support |
AWS’s advice on choosing is direct: refactoring is “the most complex and costly of the migration strategies,” and for a large migration you should “refactor only when the other migration strategies are not an acceptable option.” Rehost, relocate or replatform first, and modernize after the migration is complete. The R is an input to the cloud migration strategy, assigned in phase two. The method is what gets the portfolio moved on budget.
How Compunnel Digital helps
Compunnel Digital runs the six phases as a migration factory, with accelerators for the work that repeats from wave to wave and quality engineering built into every gate.
- Cloud migration and modernization covers the assessment, the migration and the platform modernization that follows, through cloud-native engineering, migration automation and platform modernization frameworks.
- Cloud-native accelerators shorten phases three to five. CloudForge™ is a pre-built migration factory with reusable patterns for application rationalization, wave-based planning and automated cutover testing across AWS, Azure and GCP. SecureLanding™ provides secure landing zone templates with multi-account architecture, network topology and compliance controls as infrastructure as code, and FinOpsVision™ adds real-time cost visibility and rightsizing. Compunnel reports 40% faster migrations, 15% lower total cloud spend and 10x faster environment provisioning with these accelerators.
- Cloud migration assurance is the phase-five gate: functional, integration, performance, resilience and compliance validation before cutover, and Compunnel reports 99.9% release stability across its cloud migration programs.
- FinOps and GreenOps runs phase six. Compunnel reports $12 million in annual cloud savings for a global healthcare organization and a 28% reduction in cloud spend for a retail modernization program.
On AWS, Compunnel has 650+ certified experts and more than 450 cloud transformations delivered, and on Azure it brings 1,000+ Microsoft certifications and managed operations with 24×7 monitoring. For a global education organization, Compunnel replaced a legacy Oracle data warehouse with a Snowflake cloud platform, unifying marketing, CRM, student and financial data and establishing a 20-person data and analytics center of excellence.
If you are planning a cloud migration strategy or rescuing one, talk to our team about a migration assessment.
The six-phase cloud migration plan
AWS describes migration as three phases (assess, mobilize, migrate), Google Cloud uses four (assess, plan, deploy, optimize), and Microsoft’s Cloud Adoption Framework covers the same ground in seven, from strategy through manage. The cloud migration strategy below follows that structure and adds what the frameworks leave implicit: the gate at the end of each phase that says whether the next one gets funded.
Phase 1. Strategy and business case
A cloud migration strategy starts with why. A data center lease ending, a hardware refresh avoided, a platform at end of support, readiness for AI workloads, or a regulatory requirement to keep data in-region are all legitimate reasons, and they lead to different migrations. Write the drivers down, because they decide the order of the waves and the R for each application later.
Then build the business case on numbers that can be checked: total cost of ownership today, target run cost in the cloud, one-time migration cost, and the benefits beyond cost. Decide the sovereignty position here as well. Gartner expects sovereign cloud IaaS spending to reach $80 billion in 2026, and its survey of 241 Western European CIOs found 61% expect geopolitics to increase their reliance on local cloud providers, so which workloads have residency constraints is a strategy decision to settle before wave planning starts.
Exit gate: a funded business case with a target run cost, a named program owner and a list of drivers in priority order.
Phase 2. Discover and assess
Build the application inventory with discovery tooling, then verify it with application owners. Every application needs an owner, its users, its technology, its dependencies, its data classification and its cost. The dependency map is the single most important artifact in the program, and it is where most programs are weakest: Kyndryl’s 2026 survey found only 9% of organizations fully understand their applications’ dependencies and a quarter have large numbers of undocumented applications.
Assign a preliminary R to each application from the table above. Retire aggressively, using AWS’s criteria of no business value, idle or zombie applications, and nothing with inbound connections in 90 days. Every retired application is a migration you don’t pay for.
Exit gate: every application has an owner, a dependency record, a data classification, an R and a cost baseline.
Phase 3. Mobilize
Set up the foundation before moving anything that matters. That means a landing zone, which Microsoft defines as “a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment” and which AWS and Google provide equivalents for: accounts or subscriptions, identity and access, network connectivity, security guardrails, logging, tagging standards and a cost allocation model, all as infrastructure as code so every later workload inherits the same controls. Governance retrofitted after workloads arrive is slower and leaves gaps. A May 2026 Cloud Security Alliance survey of 515 IT and security professionals found 65% had suffered at least one business-critical outage tied to a misconfigured security policy in the previous year.
Mobilize also covers the people. Decide the operating model (who runs the cloud estate after cutover), the skills plan, and the migration factory itself: the team, the tooling and the runbook template every wave will use. Then migrate a pilot wave of low-risk applications to prove all of it and produce the first real cost data.
Exit gate: the pilot wave is live, the landing zone has passed a security review, and cost data is flowing to the people who own it.
Phase 4. Plan the waves
Group applications into waves by dependency, so systems that talk to each other move together. AWS’s guidance is to keep waves within six to ten weeks, prefer smaller waves because they limit the damage from delays, and overlap waves where possible to keep throughput up. Order the waves by the drivers from phase one and by risk, and leave the most complex and most critical applications until the factory has proved itself on easier ones.
Each wave gets a runbook before it starts: the replication method, the test plan, the cutover window, the rollback trigger and the hypercare period. Writing the rollback trigger down in advance is what keeps cutover decisions simple.
Exit gate: a wave plan with a runbook, a rollback trigger and a named cutover owner for every wave.
Phase 5. Migrate, validate and cut over
Every wave follows the same runbook: replicate data, migrate, validate, cut over, then hypercare. Validation is the step teams underfund, and it is the gate. Check functionality, integrations with systems still on-premises, performance under production-like load, failover and disaster recovery, and security and compliance controls, and automate as much of it as possible so wave ten is as well tested as wave one.
Cutover is a decision made against the rollback trigger, whatever the calendar says. AWS’s guidance describes hypercare as the period after cutover in which “the migration team manages and monitors the migrated applications in the cloud in order to address any issues,” typically one to four days, before responsibility passes to cloud operations. Set it to run until the exit criteria are met: no open critical incidents, performance within target, costs within the forecast from the business case, and the application owner signing off. Only then does the source environment get decommissioned, and decommissioning is scheduled so it cannot drift, because every month of dual running is money the business case did not include.
Exit gate: hypercare exit criteria met and the source environment scheduled for shutdown.
Phase 6. Optimize and govern
After cutover the work shifts to cost, reliability and modernization, and this phase never ends. Rightsize, commit to reserved capacity where usage is stable, retire what the migration revealed as unused, and start the refactoring that was deferred in phase two. The FinOps Foundation’s 2026 survey of 1,192 practitioners, representing more than $83 billion in cloud spend, found teams reporting diminishing returns from cloud optimization alone and extending FinOps to SaaS, licensing and AI spend. Build that scope in now, because AI workloads are usually the first thing a migrated estate is asked to run.
Exit gate: a quarterly review of run cost against the business case, with the savings reinvested in modernization.
Frost & Sullivan Best Practices 2026
Global Company of the Year for Digital CX
11 pages of independent analysis. Free PDF, one short form.
Download the report →Cloud migration best practices that separate good migrations from expensive ones
- Decide the R per application, not per portfolio. A single strategy for everything either rewrites applications that only needed moving or moves applications that should have been retired.
- Make every gate a real decision. A gate that always passes is a status update, and the program finds out at cutover what it should have found out at assessment.
- Map dependencies with tooling, then verify with owners. Discovery tools find the connections; application owners explain which ones matter.
- Build the landing zone once, as code. Every later account or subscription then inherits the same security, logging and cost controls.
- Test every wave the same way. Automated regression, performance and compliance checks catch the problems that manual spot checks miss.
- Tag and allocate costs from day one. Cost ownership that starts after cutover starts with a surprise bill. Flexera estimates 29% of cloud spend is wasted, which is the margin good FinOps recovers.
- Write the rollback trigger before the cutover window. The decision then comes down to a comparison against a number, whatever time of night the window falls.
- Schedule decommissioning. Dual running is the most common hidden cost in a migration budget.
Where AI tooling fits in a cloud migration
AI tooling now does much of the mechanical work in phases two, four and five. AWS reports its agentic migration service has processed 7 billion lines of code with an estimated 2 million hours saved, and Microsoft’s Azure Migrate now includes AI-powered guidance and hand-offs to GitHub Copilot for .NET and Java upgrades. These tools speed up discovery, dependency analysis, code conversion and test generation, which is where the hours go. They don’t decide which applications matter, what the rollback trigger is, or whether a gate has been passed. In a sound cloud migration strategy, people keep the gates and the tooling takes the volume.
Planning a cloud migration, or rescuing one?
Compunnel Digital runs cloud migrations as a gated factory across AWS, Azure and GCP, from assessment and landing zone to cutover, validation and FinOps.
Explore cloud migration services →Cloud migration strategy FAQs
What is a cloud migration strategy?
A cloud migration strategy is the plan for moving applications, data and infrastructure to the cloud: which applications move, which of the 7 Rs each one gets, in what order, and the gates, owners and cost targets that govern the program from business case to governed operation.
What are the 7 Rs of cloud migration?
Retire, retain, rehost, relocate, repurchase, replatform and refactor. They describe what happens to each application in a migration, from shutting it down to rebuilding it for the cloud. AWS’s framework builds on the five options Gartner identified in 2011.
What is the difference between the 6 Rs and the 7 Rs?
The 6 Rs are the earlier AWS list: rehost, replatform, repurchase, refactor, retire and retain. AWS later added relocate, for moving virtualized environments such as VMware to the cloud without changing them, which makes seven.
What are the phases of a cloud migration?
Strategy and business case, discover and assess, mobilize, plan the waves, migrate and cut over, and optimize and govern. Each phase ends with a gate that has to be passed before the next is funded. AWS, Google Cloud and Microsoft’s frameworks cover the same ground in three, four and seven steps respectively.
How long does a cloud migration take?
It depends on portfolio size and complexity. Strategy, assessment and mobilization typically take a few months, and migration waves of six to ten weeks follow. A few hundred applications can take a year or more. Discovery tooling, a migration factory and AI-assisted conversion shorten the mechanical work.
What is a landing zone?
A landing zone is the pre-configured cloud environment workloads move into: accounts or subscriptions, networking, identity, security guardrails, logging, tagging and governance, defined as code. It is built during the mobilize phase so every workload inherits the same controls.
How do we avoid cloud cost overruns after migration?
Tag resources and assign cost ownership in the landing zone, rightsize and use committed pricing once usage is stable, retire unused resources, schedule decommissioning of the source environment, and run FinOps as a continuous practice that covers cloud, SaaS and AI spend.
Conclusion
A cloud migration strategy is a method: six phases, each with a gate, and an R assigned to every application along the way. Programs that treat it that way build the dependency map and the landing zone before moving anything, test every wave the same way, write the rollback trigger before cutover and start cost governance on day one. They spend less, finish sooner and arrive in the cloud ready to modernize.
Explore how our Cloud, Platforms and Engineering practice takes migrations from business case to governed operation.
Sources
- IDC, Worldwide Public Cloud Services Spending, March 2026
- Gartner, Worldwide IT Spending to Grow 15% in 2027, October 2026
- Gartner, Worldwide Sovereign Cloud IaaS Spending Will Total $80 Billion in 2026, February 2026
- Gartner, Geopolitics Will Drive 61% of CIOs in Western Europe to Increase Reliance on Local Cloud Providers, November 2025 (241 CIOs)
- Flexera, 2026 State of the Cloud Report, March 2026 (750+ respondents; vendor research), and cloud cost management trends
- FinOps Foundation, State of FinOps 2026 (1,192 respondents)
- Kyndryl, 2026 State of Modernization Report announcement, October 2026 (2,000 leaders; vendor research)
- AWS Prescriptive Guidance, Migration strategies, 7 Rs glossary, Migration phases and Wave planning
- Microsoft Learn, Cloud Adoption Framework overview and Azure landing zones
- AWS, AWS Transform: from migration to continuous modernization, June 2026 (vendor-reported)
- Microsoft, Accelerate migration and modernization with agentic AI, September 2025 (vendor announcement)
- Cloud Security Alliance and AlgoSec, State of Hybrid and Multi-Cloud Security Policy Management, via Virtualization Review, August 2026 (515 professionals; vendor-sponsored)
- AWS Prescriptive Guidance, Preparing your organization: cutover and hypercare
- Google Cloud, Migrate to Google Cloud: Get started
