For most legacy applications, the right cloud migration strategy is not the most advanced one—it is the one whose business driver and technical profile match your situation. Rehosting moves an application as-is for speed and minimal disruption; replatforming makes a few changes to offload maintenance; refactoring or rearchitecting rewrites code and architecture to unlock cloud-native benefits. Microsoft's Cloud Adoption Framework, which forms the backbone of the framework below, argues that this choice should be driven by an explicit business driver: a defined statement of why a workload needs to change to support a business goal.
Understanding Cloud Migration Strategies
Most enterprise migrations are organized around a family of strategies commonly called the "R" strategies. IBM's overview of the 7 R's lists them as rehost (lift-and-shift), relocate, replatform, refactor or rearchitect, repurchase, retire, and retain, noting that each represents a distinct approach with specific use cases and trade-offs. The set is broader than many IT leaders assume: two of the seven involve not migrating at all.
The strategies differ mainly in how much change the application undergoes. Rehosting leaves the application untouched and moves it to cloud infrastructure. Replatforming keeps the underlying architecture intact but changes components that run on it, such as databases or operating systems, as Analytics8's migration guide explains. Refactoring and rearchitecting go further, altering code or the architecture itself. Retire, replace, and retain round out the portfolio: decommissioning what is no longer needed, substituting a SaaS product, or deliberately leaving a workload where it is.
The Cloud Migration Strategy Decision Framework
The table below adapts Microsoft's Cloud Adoption Framework guidance, which links each strategy to a primary business driver and the key indicators that suggest it fits your workload. To use it, characterize your application—its stability, business value, code condition, and customization needs—then find the row whose indicators describe it. Where sources describe a strategy differently, the row reflects the primary framing.
| Strategy | Primary Business Driver | Key Indicators | Typical Situation |
|---|---|---|---|
| Retire | Decommission redundant or low-value workloads | Limited current or future business value; migration or modernization cost outweighs benefits | Applications that would be difficult or troublesome to migrate, per Yugabyte's guidance; time the shutdown so users are not cut off mid-use |
| Rehost | Minimal business disruption, no near-term modernization | Stable workload, low-risk migration, short-term cloud adoption goals, desire to reduce capital expense and free datacenter space | Quick wins for organizations new to the cloud or exiting a datacenter |
| Replatform | Offload maintenance and improve reliability with minimal code changes | Desire to simplify disaster recovery, reduce OS and licensing overhead, containerize the app, with moderate investment | Modernizing the runtime (databases, operating systems) while keeping the architecture, as Analytics8 describes |
| Refactor / Rearchitect | Reduce technical debt or unlock cloud-native capabilities | Need to improve code performance and cost, apply cloud design patterns, modularize or decompose services, support scaling that varies by component | Applications whose long-term value justifies the highest cost and effort |
| Replace (Repurchase) | Simplify operations with a SaaS solution | Little need for customization; internal development resources better used elsewhere | Moving away from managing installed applications, or switching from IaaS to SaaS delivery |
| Retain | Stability with no change | Workload is stable, compliant, meets business needs; low migration ROI | Workloads revisited later rather than forced into the current wave |
Microsoft's framework also lists Rebuild—creating a new cloud-native solution when the legacy system is too outdated or inflexible—as a separate option for teams needing modern frameworks and faster application delivery. If an application's indicators point in two directions, the business driver should break the tie: cost-driven programs favor the low-change end, while agility-driven programs justify higher investment.
Key Trade-offs: Speed, Cost, and Long-Term Benefits
The central trade-off across these strategies is speed and initial cost today versus cloud-native benefit tomorrow. Rehosting is the fastest path with the fewest moving parts, which is why AWS's prescriptive guidance for large migrations recommends rehosting, relocating, or replatforming first and modernizing after the migration completes. Its reasoning is direct: refactoring modernizes the application during migration, making it the most complex strategy to manage across a large number of applications.
At the other end, refactoring is costly and time-consuming—but Yugabyte's analysis calls it the most future-proof strategy, one that done properly may result in significantly lower operating costs than the legacy architecture. Analytics8's guide frames rearchitecting as often the most expensive option, since it requires reimagining how the application is developed. Replatforming occupies the middle ground: a few modifications yield noticeable benefits without a rebuild.
The practical implication is that the strategies are sequenced, not just ranked. An organization can rehost a workload to exit a datacenter quickly, then replatform or refactor later once it has cloud experience. Choosing the least disruptive strategy now does not forfeit deeper modernization; it defers it. What it does forfeit, per Microsoft's framing, is immediate access to cloud-native capabilities such as improved code performance and cloud design patterns.
Critical Planning Considerations for Migration Success
The framework only works if you arrive at it prepared. Akamai's migration guidance recommends establishing clear goals first—cost savings, improved performance, or increased agility—because defined objectives guide every downstream decision, including which strategy and which applications to choose. Just as important, decide the metrics you will track before and after the migration, such as the daily cost of compute resources, so you can report cost-effectiveness to stakeholders.
Two risks deserve explicit attention. An IBM Institute for Business Value 2023 report found that approximately 58% of global decision-makers say cloud skills remain a considerable challenge—a gap that weighs most heavily on the high-change strategies like rearchitecting. And without proper governance, IBM's authors warn, cloud costs can spiral as teams spin up resources without understanding pricing. Skills and governance constraints are legitimate reasons to choose a lower-effort strategy for the first migration wave.
Finally, assess the current IT landscape before committing. Yugabyte's guidance emphasizes having a plan to avoid disruptions and maximize cloud benefits, and its retire guidance illustrates why: even decommissioning an application must be timed so that people relying on it are not cut off mid-use, with a replacement identified quickly.
Selecting the Optimal Strategy for Your Application
To put all of this together, evaluate each legacy application through four questions. First, does it still earn its keep? If its business value is limited or the migration cost outweighs the benefit, retire or retain it. Second, how urgent is the move? Short-term goals like freeing datacenter space or reducing capital expense point to rehosting. Third, how much change can the application and team absorb? If maintenance burden is the pain point and code changes must stay minimal, replatform; if customization needs are low and operations must simplify, replace with SaaS. Fourth, what is the long-term destination? Applications requiring modularization, component-level scaling, or cloud design patterns justify refactoring or rearchitecting—provided they are not part of a large initial wave.
Answering these four questions in order produces a defensible, documented rationale for each workload, which is itself valuable when stakeholders question why one application was lifted and shifted while another was rewritten.
Making an Informed Migration Decision
IT leaders should select a cloud migration strategy by aligning each application's characteristics and business objectives with the specific trade-offs of each R strategy, prioritizing clear goals and a thorough landscape assessment before the first workload moves. The decision is workload-by-workload, not enterprise-wide: a single portfolio will typically contain a mix of rehosts, replatforms, retirements, and one or two carefully chosen rearchitecting efforts.
A successful migration decision will be indicated by the chosen strategy's alignment with established cost, performance, and agility metrics post-migration. That means the practical next step is concrete: before migrating, define the metrics—such as daily compute cost—you will measure, record their baseline, and after migration verify whether the strategy is delivering against them. The evidence supports using alignment as the test of the decision, not a guaranteed outcome; where a rehosted workload fails to meet its cost or agility targets, that result itself signals which workloads to prioritize for replatforming or refactoring in the next wave.
Sources
- Select your cloud migration strategies - Cloud Adoption Framework — LEARN
- The 7 R's of Cloud Migration — IBM
- Cloud Migration Strategy Guide and Checklist|Cloud Migration Strategy Guide and Checklist — Analytics8
- What Are the 7 Types of Cloud Migration? — Yugabyte
- About the migration strategies - AWS Prescriptive Guidance — DOCS
- Cloud Migration Strategy: The Step-By-Step Framework and Benefits — Akamai
