Cloud Migration Strategies: The 7 Rs and How to Choose

Cloud migration is rarely one technical move repeated across every application. An estate usually contains easy candidates, fragile legacy systems, commercial products, databases with hard dependencies, workloads that should be retired, and applications that need redesign before they can benefit from cloud services. Treating all of them the same is how migration programs become slow, expensive, and risky.

A practical planning model is the “7 Rs.” AWS currently describes the seven strategies as retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Other providers use similar language with small naming differences. The value of the framework is not the letter count. It forces teams to decide what kind of change each workload actually needs before migration waves are scheduled.

The right strategy depends on business value, technical constraints, risk tolerance, licensing, deadlines, operational maturity, and what the organization hopes to gain after the move.

Retire removes systems that no longer justify migration effort

Migration discovery often reveals servers and applications that are barely used, duplicated, replaced by another system, or kept alive because nobody wants to own the shutdown decision. Moving them to the cloud preserves cost and complexity without preserving value.

Retirement should be evidence-based. Confirm users, integrations, data-retention requirements, regulatory obligations, and downstream dependencies before decommissioning. A system with low CPU utilization may still perform an important monthly or quarterly function.

When the evidence supports retirement, remove it deliberately. Archive required data, document the decision, update service catalogs, revoke identities, close firewall paths, and stop backups or monitoring that no longer serve a purpose.

Retain is a valid strategy when timing or constraints make migration irrational

Some workloads should stay where they are for now. They may depend on specialized hardware, be near end of life, have unresolved licensing constraints, or be scheduled for replacement in a year. A rushed migration can consume more effort than the remaining business life of the application.

Retain does not mean “ignore forever.” Record why the workload is staying, which risk or dependency blocks migration, and when the decision will be reviewed. That keeps retained systems from becoming invisible technical debt.

Hybrid architecture often exists because retain is legitimate. The cloud environment still needs secure connectivity, identity integration, monitoring, and operational procedures that span on-premises and cloud resources.

Rehost moves the workload with the least application change

Rehosting, often called lift-and-shift, moves a workload to cloud infrastructure while preserving most of its existing architecture. It can be effective when the primary objective is data-center exit, hardware refresh avoidance, or a fast move under a fixed deadline.

The benefit is speed and lower application-change risk. The weakness is that the workload may carry old assumptions into a new cost model. A server sized for peak demand on purchased hardware may be wasteful when run continuously in the cloud. Manual patching, static capacity, and tightly coupled components remain manual and tightly coupled after the move.

Rehost is therefore often a first step rather than a final state. Plan a later optimization phase so the organization does not declare victory once the virtual machines are merely running somewhere else.

Relocate moves an existing platform without redesigning the workloads on it

Relocate is useful when a whole virtualized or platform environment can move with little change to the individual applications. VMware-based migration patterns are a common example. The organization changes the hosting location while preserving much of the platform and operational model.

This can reduce migration effort for large estates, but it also postpones some cloud-native benefits. The team should be clear about whether relocation is a long-term operating model or a bridge toward later modernization.

The strategy is strongest when continuity and speed matter more than immediate architectural improvement.

Repurchase replaces the application with a different product

Sometimes the most sensible migration is not to migrate the application at all. A legacy CRM, collaboration system, ticketing platform, or analytics product may be better replaced by a SaaS service or newer commercial offering.

Repurchase shifts work from infrastructure migration to data migration, integration, identity, process change, and user adoption. Those are not trivial concerns. A SaaS replacement can fail if teams underestimate data cleanup, custom workflows, reporting dependencies, or contractual requirements.

The business case should compare total operating cost and capability, not just the hosting bill. A replacement can reduce infrastructure work while introducing subscription cost and provider dependency.

Replatform changes selected components without rewriting the whole application

Replatforming keeps the application’s basic architecture but swaps some infrastructure for managed cloud services. A database might move from a self-managed VM to a managed relational service. An application may move into a managed container platform. File storage may become object storage.

This strategy often gives a strong balance between speed and improvement. The application team gets operational benefits without taking on the risk of a full redesign. The challenge is understanding compatibility, performance, backup, monitoring, and provider-specific limits before the migration window.

Architecture review becomes important during replatforming because the team must decide which managed services genuinely reduce toil without breaking compatibility, recovery, observability, or cost assumptions. Replatforming succeeds when the target service improves the operating model rather than simply changing the product name.

Refactor or re-architect changes the application to use a different design

Refactoring can produce the largest long-term benefit and the highest short-term risk. The team may break a monolith into services, adopt asynchronous messaging, move to serverless compute, redesign data stores, or build a new deployment architecture.

That level of change should be justified by business value. “Cloud native” is not enough of a reason. Refactor when the current architecture blocks scale, delivery speed, reliability, cost goals, or product capability in a way that smaller changes cannot solve.

AWS’s large-migration guidance explicitly cautions that refactoring is usually the most complex strategy and is often better performed after a large migration rather than during the first move. That advice captures an important principle: do not combine infrastructure relocation and deep application redesign unless the program can absorb both kinds of risk.

Choose the strategy per application, not per migration program

A portfolio assessment should classify workloads by business criticality, technical health, dependencies, data sensitivity, licensing, lifecycle, and desired target state. Then assign a strategy that fits each workload.

Dependencies can override a seemingly obvious decision. An application ready to replatform may still depend on a database that must remain on-premises. A low-value service may be simple to rehost but should really be retired. A system selected for refactoring may be replaced by a new product before the redesign pays back.

Cloud architects need to think at portfolio level. Migration strategy is ultimately a requirement-and-trade-off problem: business value, technical health, dependencies, supportability, data gravity, deadlines, and target operating model all influence the right choice for each workload.

Migration waves need operational readiness as much as technical readiness

Even a technically successful migration can fail operationally if monitoring, backup, identity, support ownership, cost controls, and incident response are not ready on day one. Each wave should have a clear cutover plan, rollback criteria, validation steps, and named owners.

Landing-zone readiness matters too. If every team invents new account structure, networking, logging, and security controls during migration, the program becomes a governance project at the same time as an application move.

The strongest migration programs therefore build the foundation first, classify workloads honestly, select strategies individually, and separate “moved” from “modernized.” The cloud is not the outcome. The outcome is an estate that is easier to operate, safer to change, and better aligned with the business than the one it replaced.

Data deserves its own migration strategy because application movement and data movement have different physics. Large databases may require replication, change-data capture, staged synchronization, or extended transfer windows. The team must decide how to validate completeness, handle writes during cutover, protect sensitive data in transit, and roll back if the application migration succeeds but the data state does not.

Dependencies also affect wave design. A front-end service may be easy to rehost but useless without an on-premises database. A database may be ready for a managed cloud service while five legacy applications still require its old interface. Migration sequencing should follow dependency graphs rather than organizational charts.

Migration decisions need to connect identity, networking, continuity, governance, licensing, data movement, and business constraints. Treating migration as a server-copy exercise hides the operational dependencies that usually determine whether the new environment is actually easier to run.

After each wave, measure more than whether the workload is live. Track incident rate, performance, cloud cost, manual operational effort, unresolved dependencies, and modernization debt. A migration can meet its cutover date while making the system more expensive or harder to support. Those outcomes should influence the strategy selected for later waves.

Licensing and commercial support can also change the best strategy. Some enterprise software is licensed by processor, host, or deployment model; other products have cloud marketplaces or managed replacements that alter the economics completely. Migration teams should involve procurement and vendors early enough that a technically elegant target is not invalidated by support or licensing constraints after design work is complete.