In 2011, the U.S. National Institute of Standards and Technology published a definition of cloud computing that is still cited today: a model for enabling on-demand network access to a shared pool of configurable computing resources. More than a decade later, that definition has aged well, but the hard part was never what the cloud is. It is how to get there without breaking production, blowing the budget, or losing your best engineers to burnout. That is the job of a cloud migration framework.
A cloud migration framework is a structured set of phases, decision models, and governance checkpoints that turns a vague “we should move to the cloud” ambition into a sequenced, auditable program. It tells you what to assess first, which workloads to move, in what order, and how to prove the move worked.
Why frameworks beat improvisation
Improvised migrations tend to follow a predictable arc: an enthusiastic pilot, a stalled second wave, then a cost overrun that freezes the whole program. Frameworks exist because the failure modes are so consistent across industries.
The best-known reference points come from the major providers and from independent analysts. The AWS Cloud Adoption Framework organizes guidance into six perspectives: Business, People, Governance, Platform, Security, and Operations. Microsoft’s Cloud Adoption Framework for Azure runs through Strategy, Plan, Ready, Adopt, Govern, and Manage. Google Cloud’s adoption framework is built around four phases: Learn, Lead, Scale, and Secure. None of these is “correct” in an absolute sense; they are lenses, and most mature organizations blend them.
What all three share is a simple insight: migration is a people and process problem wearing a technology costume. The technical move of a virtual machine is often the easy part. The hard parts are ownership, funding models, security sign-off, and the uncomfortable conversation about which applications should simply be retired.
For a broader primer on the underlying technology, it helps to understand what cloud storage is and how it works before designing a migration sequence around data.
The phases of a workable migration framework
Most credible frameworks, whatever their branding, collapse into five practical phases. Skipping any one of them is where programs go wrong.
1. Assess and inventory
You cannot migrate what you have not catalogued. Assessment means building an application inventory with, at minimum: business owner, criticality tier, dependency map, data classification, current hosting cost, and technical debt rating.
A common mistake here is treating the CMDB (configuration management database) as sufficient. It rarely is. CMDBs are often stale, and they rarely capture the informal dependencies that break cutovers, such as a batch job on a forgotten server that feeds a reporting database nobody owns. Practical tip: run automated discovery for a full billing cycle, then reconcile it against the CMDB manually. The delta is usually where the surprises live.
2. Choose a migration strategy per workload
This is the heart of the framework. Gartner’s early framing of migration options, later popularized by AWS as the “6 Rs” and extended to a “7 Rs” variant, gives teams a shared vocabulary.
| Strategy | What it means | Typical fit | Effort |
|---|---|---|---|
| Rehost | Lift and shift, minimal change | Legacy apps, tight deadlines | Low |
| Replatform | Minor tuning, e.g. managed database | Apps with clear quick wins | Medium |
| Repurchase | Replace with SaaS | Commodity functions like HR or email | Low to medium |
| Refactor | Rearchitect for cloud-native patterns | High-value, fast-changing systems | High |
| Retain | Keep where it is for now | Regulated or not-yet-justified workloads | None |
| Retire | Decommission | Duplicate or unused systems | Low |
The retire column is the most underused. In practice, a thorough assessment usually finds that a meaningful share of applications have no active users or duplicate a function already provided elsewhere. Retiring them before migrating anything reduces scope, cost, and risk simultaneously.
3. Plan the wave sequence
Workloads move in waves, not all at once. A sensible wave groups applications by shared dependency, business unit, or cutover window. Sequencing rules that work in practice:
- Start with low-criticality, low-dependency applications to build the team’s capability.
- Never schedule two high-risk cutovers for the same weekend.
- Front-load the workloads that prove the operating model, not the easiest ones.
- Reserve a final “hard cases” wave for the systems everyone has avoided.
4. Execute and cut over
Execution discipline matters more than tooling. Freeze windows, rollback plans, and a single accountable cutover owner per wave prevent the classic failure where three teams each assume someone else validated the DNS change.
One useful comparison point: the difference between cloud storage vs local storage is well understood for end-user files, but the same trade-offs around latency, egress, and durability apply to application data during cutover. Teams that model egress costs and data gravity early avoid nasty invoice surprises.
5. Tune and govern
Migration does not end at cutover. The tuning phase covers rightsizing, reserved capacity, storage tiering, and eliminating orphaned resources. Governance covers tagging standards, budget alerts, and access reviews.
This is also where provider choice gets revisited. A comparison of AWS vs Azure vs Google Cloud is worth running after the first wave, when you have real consumption data rather than vendor slideware.
The 7 Rs in more detail
The strategy table above is a starting point, but each “R” deserves a sentence of nuance, because teams routinely misapply them.
Rehost is fast and cheap per application, but it carries the migration debt forward. A lifted server is still a server to patch. Use it to hit a data center exit deadline, not as a default.
Replatform is the sweet spot for many organizations. Moving a self-managed database to a managed service, or a homegrown queue to a cloud-native one, captures real operational savings without a rewrite.
Refactor delivers the biggest long-term benefit and the biggest short-term risk. Reserve it for systems with genuine business differentiation and a stable product roadmap.
Repurchase is often the fastest path for back-office functions, but watch for integration sprawl and per-seat cost creep.
Retain is not failure. Some workloads have regulatory, latency, or licensing reasons to stay put, at least for now. Documenting why something is retained is as valuable as documenting what moves.
Retire should be a standing agenda item in every wave review, not a one-time assessment activity.
Relocate, the seventh R, applies when you move a workload at the hypervisor level without changing it, common in VMware-based estates.
Where frameworks collide: multi-cloud and AI workloads
Frameworks designed for a single provider get strained in multi-cloud estates. The emerging pattern is a thin central framework covering identity, networking, security, and FinOps, with provider-specific playbooks underneath. Trying to force one vendor’s framework across an entire multi-cloud estate usually produces documentation nobody reads.
AI workloads add a new wrinkle. Training and inference have different migration characteristics from traditional applications: data locality matters more, GPU capacity is scarce, and cost models are volatile. The architecture questions raised by Apple’s private cloud compute and Google Cloud in 2026 illustrate how confidential computing and provider-specific AI infrastructure are reshaping placement decisions. Similarly, specialized inference platforms such as the Cloudflare Clef Omni 30B multimodal decision model show why “where does this model run” is now a first-class migration question rather than an afterthought. (Cloud migration)
For teams building generative features, understanding how AI image generation works helps clarify which parts of the pipeline belong in the cloud and which can run at the edge.
Common mistakes that frameworks are supposed to prevent
Migrating without a business case per application. A program-level business case hides the fact that some applications cost more in the cloud. Build the case per workload.
Treating security as a gate at the end. Security review should run in parallel with assessment, not as a final approval step. Late security findings are the single most common cause of wave delays.
Underestimating the operating model change. The technology moves in months; the operating model takes years. Teams that fund a platform engineering function before the first wave consistently report smoother cutovers.
Ignoring data transfer and egress economics. Storage looks cheap until you model retrieval patterns. Model them explicitly.
No exit criteria. Every wave needs a definition of done: performance baselines met, monitoring live, runbooks updated, cost within forecast tolerance.
A realistic timeline
For a mid-sized enterprise with a few hundred applications, a typical program runs 18 to 36 months. Assessment and planning occupy the first three to six months. The first wave lands around month six to nine. Waves two through five run roughly quarterly. Optimization and decommissioning of the old estate continue for a year after the final cutover.
The organizations that finish on schedule are rarely the ones with the best tools. They are the ones that scoped aggressively, retired early, and kept a single accountable owner for the program.
Conclusion
A cloud migration framework is not a document you buy or download. It is a set of decisions made explicit: what you will move, in what order, with what strategy, and how you will know it worked. The provider frameworks from AWS, Microsoft, and Google give you solid scaffolding, and the 7 Rs give you a shared language for the hardest conversation in any migration, which is the one about what not to move.
Start with an honest inventory. Retire before you migrate. Sequence waves so each one teaches you something. And treat governance and cost optimization as permanent functions rather than project phases. Do those four things, and the framework becomes what it should be: a way to keep a large, messy program from becoming a large, messy surprise.
What is a cloud migration framework?
A cloud migration framework is a structured set of phases, decision models, and governance checkpoints used to plan and execute moving applications and data to cloud infrastructure. It typically covers assessment, strategy selection, wave planning, execution, and post-migration optimization, along with the security and financial controls that run across all of them.
How many migration strategies are there?
The count varies by source. Gartner’s early framing used five options, AWS popularized six, and a seven-strategy variant adds relocate for hypervisor-level moves. The practical set most teams use is rehost, replatform, repurchase, refactor, retain, and retire, with relocate added for VMware-based estates.
Which provider framework should an organization choose?
Most organizations should not pick just one. AWS, Microsoft, and Google each publish frameworks organized around different phase names but covering similar ground. A workable approach is to adopt one as the primary structure, borrow the assessment and governance elements from the others, and keep provider-specific playbooks underneath a thin central framework.
How long does a cloud migration take?
For a mid-sized enterprise with a few hundred applications, 18 to 36 months is typical. Assessment and planning take three to six months, the first wave lands around month six to nine, and subsequent waves run roughly quarterly. Optimization and decommissioning of the legacy estate often continue for a year after the final cutover.
What is the biggest cause of migration delays?
Late security and compliance findings are the most common cause of wave delays, followed by stale application inventories that miss informal dependencies. Running security review in parallel with assessment, and reconciling automated discovery against the CMDB, removes most of the friction before it reaches a cutover weekend.
Should every application be migrated?
No. A thorough assessment usually identifies applications with no active users, duplicate functions, or regulatory reasons to stay put. Retiring unused systems and formally retaining the rest reduces scope, cost, and risk. Documenting the reason for retention is as valuable as documenting what moves.
