The 6 Rs of Cloud Migration, Revisited

The 'Rs' of cloud migration began as Gartner's five strategies and have since expanded — AWS added Retire and Retain to make six, then Relocate to make seven. The taxonomy is useful, but the number is a distraction. What determines whether a migration succeeds is not which clever label you attach to each workload; it is the discipline of assigning the right strategy per workload, sequencing the work into sensible waves, and resisting the urge to modernize everything at once. The Rs are a vocabulary for those decisions, not a substitute for making them.

The strategies, briefly

• Rehost (lift and shift): move the workload as-is. Fast and low-risk, ideal for getting out of a data center quickly; modernize later.
• Relocate: move at the hypervisor level — whole virtual environments transferred without rebuilding. Lift-and-shift for virtualized estates.
• Replatform (lift and tinker): make targeted improvements during the move, such as swapping a self-managed database for a managed one, without rewriting the app.
• Repurchase: drop the workload in favor of a SaaS product — common for CRM, email, and other commodity capabilities.
• Refactor: re-architect for the cloud — the most valuable and most expensive option, and the one to defer on large migrations.
• Retire: switch it off. The cheapest migration is the one you don't do because the workload is no longer needed.
• Retain: leave it where it is, for now — because of latency, compliance, or a cost-benefit that simply doesn't favor moving.

Refactor is rarely the right first move

The most common and most expensive mistake is to treat migration and modernization as the same project. Refactoring during a migration sounds efficient — why move it twice? — but it multiplies risk: you are simultaneously changing where the application runs and how it works, which makes failures hard to diagnose and timelines impossible to predict. For large estates the durable pattern is to rehost or replatform first to get off the legacy infrastructure, stabilize, and then modernize selectively once the workload is in the cloud and you can see its real behavior. Modernization is easier and safer when it is not also a relocation.

Migrate first, modernize second. Changing where something runs and how it works at the same time is the fastest way to a migration that slips and a rollback nobody planned for.

Waves, not a big bang

A large migration is not one event; it is a sequence of waves. Group workloads by dependency, risk, and business value, and move them in batches that you can validate before proceeding. Early waves should be low-risk workloads that build the team's muscle and prove the landing zone — the network, identity, security, and account structure the migrated workloads will live in. Higher-risk, business-critical systems come later, once the patterns are proven and the team trusts the process. Each wave should have explicit success criteria: expected spend, performance benchmarks, and a tested cutover and rollback plan.

The decisions that actually matter

In regulated and legacy environments, the migration strategy per workload is the easy part. The decisions that determine success are quieter: getting the landing zone right so you are not retrofitting security and networking later; deciding what to retire before you waste effort moving dead weight; and being honest about what should be retained because the cost or risk of moving it outweighs the benefit. A disciplined assessment that classifies every workload, prioritizes by value and complexity, and plans the waves is worth more than any amount of enthusiasm for refactoring.

Revisited, the Rs are best understood not as a menu to pick from once but as a lens applied component by component. The same application might have a front end you replatform, a database you replatform onto a managed service, an integration you retire, and a core engine you defer refactoring until after the move. Granularity at that level — and the patience to sequence it — is what separates migrations that deliver from migrations that drag.