What do you do when a company’s aging data center lease runs out in eleven months, the finance team wants predictable costs, and the engineering team is already stretched thin? That is not a technology question. It is a planning question. And planning is exactly what a cloud migration framework is built to handle.
A framework gives a move to the cloud a spine: shared vocabulary, clear phases, defined decision points, and a way to know when you are actually done. Without one, migrations tend to drift into long, expensive projects that nobody can quite declare finished. This article walks through the major frameworks, how they differ, and what actually works in practice.
What a Cloud Migration Framework Actually Is
A cloud migration framework is a structured method for moving workloads from on-premises infrastructure (or one cloud) to another environment. It typically covers four things: an assessment of what exists, a plan for how each workload will move, an execution phase, and a post-migration optimization phase.
It helps to separate two kinds of frameworks that get confused constantly.
Process frameworks describe the phases of a migration program: strategy, planning, readiness, migration, governance, and operations. They answer “how do we run this project?”
Strategy taxonomies describe what you do to each individual application: rehost it, refactor it, retire it, and so on. They answer “what happens to this specific workload?”
Most mature migration programs use both. The process framework keeps the program on track; the taxonomy keeps individual decisions honest.
One important caveat: there is no single international standard that prescribes a migration process. The International Organization for Standardization defines cloud vocabulary and reference architecture through ISO/IEC 17788 and 17789, but those documents describe what cloud computing is, not how to migrate to it. Any framework you adopt is a vendor methodology or an industry convention, not a legal requirement.
The Big Three Process Frameworks
Three process frameworks dominate enterprise practice. They overlap heavily, and the differences matter less than whether you actually follow one.
| Framework | Owner | Main Phases | Best Fit |
|---|---|---|---|
| AWS Cloud Adoption Framework (CAF) | Amazon Web Services | Six perspectives: Business, People, Governance, Platform, Security, Operations | Organizations already committed to AWS |
| Microsoft Cloud Adoption Framework | Microsoft | Strategy, Plan, Ready, Adopt, Govern, Manage | Azure-centric estates, especially hybrid |
| TOGAF | The Open Group | Architecture development method with migration planning phases | Large enterprises with existing EA practice |
The AWS CAF was substantially restructured in 2021 around its six perspectives. It is less a step-by-step checklist and more a map of organizational capabilities you need to build. That makes it strong for identifying gaps (say, no cloud financial management function) but weaker as a day-to-day project plan.
Microsoft’s framework is more explicitly phased, which many teams find easier to operationalize. Its Strategy and Plan phases force early conversations about business justification and skills readiness before anyone provisions a subscription.
TOGAF is not cloud-specific at all. It is an enterprise architecture method, and teams use it when migration work has to slot into a broader architecture governance structure. If your organization already runs TOGAF, bolting a separate migration method on top usually creates duplicate governance. If it does not, adopting TOGAF purely for a migration is heavy.
The Migration Strategies: 5 Rs, 6 Rs, 7 Rs
The application-level taxonomy is where most arguments happen, largely because different sources count differently.
The most widely cited version is the six strategies popularized by AWS: rehost (lift and shift), replatform (lift, tinker, and shift), repurchase (move to a different product, often SaaS), refactor (re-architect), retain (keep it where it is, for now), and retire (switch it off). The AWS six migration strategies guidance explains each in AWS’s own words.
Earlier, Gartner described a set of “5 Rs” that is often credited as the origin of the taxonomy. Some consultancies now use “7 Rs,” adding options like relocate (moving a VM wholesale to another platform without changes). Definitions vary between sources, so the practical advice is simple: pick one taxonomy, attribute it, and use it consistently across your program. Do not mix vocabularies between teams, because “replatform” means subtly different things to different people.
Why the Taxonomy Matters More Than You Think
Here is where experience beats theory. The single most common mistake in cloud migration is treating rehost as the default and refactoring as the aspiration. Rehosting is fast and low-risk per application, but it carries every existing inefficiency into the new environment. Teams that lift and shift everything often find their cloud bill higher than the data center it replaced, because they are paying cloud prices for unoptimized workloads.
The second common mistake is the opposite: an ambitious refactor-everything mandate that stalls after the first two applications. Refactoring takes real engineering time, and doing it across a large portfolio while also running the business is rarely realistic.
What actually works is a portfolio approach. Sort applications into buckets, then commit to a realistic mix. A rough rule of thumb many practitioners use is that the majority of a typical estate can be rehosted or replatformed, a meaningful minority retired or repurchased, and only a small share genuinely refactored in the first wave. The refactoring candidates should be the ones where the business case is clearest: high-change applications, expensive licensing, or workloads that will genuinely benefit from managed services.
Retirement deserves special attention. In most large estates, a surprising number of applications have almost no active users. Finding and switching off those systems before migration is the cheapest win available, and it is routinely skipped because nobody owns the decision.
Assessment: The Phase Everyone Rushes
Assessment is where migrations are won or lost, and it is the phase teams most often compress under deadline pressure. A proper assessment answers: what applications exist, what do they depend on, who owns them, what data do they hold, and what is their actual usage?
The dependency mapping part is where surprises live. An application that looks standalone often shares a database, an identity provider, or a batch job with three other systems. Move it without mapping those links and something breaks at 2 a.m. A structured inventory checklist for cloud migrations helps here, because the failure mode is not ignorance of the method but forgetting a category entirely, such as scheduled jobs, integrations, or certificate dependencies.
Two practical tips from the field. First, automate discovery where you can, but verify with application owners, because automated tools miss undocumented connections constantly. Second, capture the assessment as a living document, not a one-time report. Estates change during a long migration.
Planning and Landing Zones
Once assessment is done, planning turns into two parallel tracks: the migration wave plan and the target environment.
The landing zone is the pre-built, governed foundation: accounts or subscriptions, network topology, identity, logging, guardrails, and cost controls. Building it before the first workload moves saves enormous rework. Teams that skip it end up retrofitting security controls and account structures onto live systems, which is far more painful.
Wave planning is about sequencing. Group applications by dependency, by business criticality, or by team ownership, then move in waves small enough to learn from and large enough to matter. A first wave of one or two low-risk applications is a sensible pilot; a first wave of forty is a gamble.
This is also the stage to think about account and subscription boundaries. Splitting workloads across separate accounts limits blast radius and simplifies cost attribution, and there is a reasonable case for splitting workloads across cloud accounts early rather than reorganizing later.
Execution, Cutover, and the Things That Break
Execution is the visible part, and it is usually the shortest phase per application. The hard parts are cutover logistics and data synchronization.
For each workload, define a cutover plan with a rollback path. Test the rollback. A migration without a tested way back is not a plan, it is a hope. For databases, plan the replication and the final sync window explicitly, and rehearse the cutover at least once in a non-production environment.
Common failure points, in rough order of frequency:
- Identity and access. Permissions that worked on-premises do not map cleanly to cloud role models.
- Network dependencies. Hard-coded IP addresses, firewall rules, and latency-sensitive calls between systems.
- Data gravity. Large datasets that take longer to transfer than the project plan assumed.
- Licensing. Software licenses that do not permit cloud deployment, or that become dramatically more expensive under cloud licensing terms.
- Monitoring gaps. Observability that was implicit in the data center and has to be rebuilt.
Data transfer costs deserve their own line item. Egress charges and inter-region traffic can quietly reshape a budget, so it pays to have a clear method for tracking cloud data transfer costs before the bills arrive rather than after.
Governance, Security, and Cost Control
Governance is not bureaucracy; it is what stops a migration from creating a shadow estate. The essentials are a tagging standard, a policy set enforced through the platform rather than through review meetings, and a clear ownership model for every workload.
Security deserves early, dedicated attention. The cloud security model is shared responsibility: the provider secures the infrastructure, and you secure what you put on it. Misconfigurations, not provider breaches, cause most cloud incidents. Building guardrails into the landing zone, such as enforced encryption, blocked public storage, and centralized logging, prevents whole categories of problem. A structured approach to enterprise AI and cloud security is worth establishing before the first production workload lands, especially as AI services enter the estate.
Cost control follows the same logic. Tagging plus budget alerts plus a regular review cadence beats reactive bill shock. The trick is making cost reviews useful to the people who can act on them, which usually means showing engineers their own team’s spend in units they recognize rather than a single company-wide number. There is good guidance on making cloud cost reviews useful to engineers that covers this in more depth.
Optimization: The Phase That Never Ends
Migration is not finished when the last application moves. It is finished when the new environment is stable, right-sized, and cheaper or better than what it replaced.
Optimization covers rightsizing instances, adopting reserved capacity or savings plans, eliminating orphaned resources, and revisiting the workloads that were rehosted with the intention of improving them later. That “later” needs a date, or it never comes.
This is also when teams should revisit their original business case honestly. Did the costs land where the plan said? Did performance improve? What would they do differently in the next wave? Feeding those answers back into the framework is what turns a one-off project into an organizational capability.
Conclusion
A cloud migration framework will not make a migration easy, but it will make it legible. The process frameworks from AWS, Microsoft, and The Open Group give structure; the migration strategy taxonomies give you a shared language for individual decisions. Neither substitutes for the unglamorous work: mapping dependencies properly, building a landing zone before you need it, retiring what nobody uses, and testing the rollback.
The teams that migrate well tend to share three habits. They pick one framework and stick to it rather than blending vocabularies. They treat assessment as an investment rather than an obstacle. And they plan for optimization from day one, so the cloud move leaves a better estate rather than the old one at a new address.
Frequently Asked Questions
What is the difference between a cloud migration framework and a cloud adoption framework?
A migration framework focuses on moving specific workloads: assessment, planning, execution, and cutover. A cloud adoption framework is broader and covers the organizational capabilities needed for cloud in general, including people, governance, security, and operations. In practice, most organizations use an adoption framework as the outer structure and a migration method within it.
Which migration strategy should most applications use?
For most estates, rehost and replatform cover the majority of applications. Rehosting is fast and low-risk but carries existing inefficiencies into the cloud, so it works best as a first step with a scheduled follow-up. Refactoring should be reserved for workloads with a clear business case, since it consumes significant engineering time.
Is there an official standard for cloud migration?
No. There is no ISO or NIST standard that prescribes a migration process. Standards bodies define cloud vocabulary, reference architecture, and security guidance, but migration methodology comes from vendor frameworks and industry convention. That is why frameworks differ in phase names and strategy counts.
How long does a cloud migration take?
It depends heavily on estate size and complexity. A small, well-understood set of applications can move in weeks. Large enterprise estates commonly take one to three years across multiple waves. The more useful question is how long each wave takes, since wave-based delivery gives far better predictability than a single end date.
What is a landing zone and why does it matter?
A landing zone is the pre-configured foundation for cloud workloads: accounts or subscriptions, networking, identity, logging, security guardrails, and cost controls. Building it before workloads move prevents expensive retrofitting later. Skipping it is one of the most common causes of security and cost problems in the first year.
What is the biggest mistake in cloud migrations?
Treating rehosting as the whole strategy. Lifting and shifting everything is fast, but it often produces a cloud bill higher than the data center it replaced, because unoptimized workloads are expensive at cloud prices. A portfolio mix with a planned optimization phase avoids this.
