The 6 R’s of Cloud Migration, Explained
Every workload in your datacenter gets one of six fates. Getting the classification right is the single highest-leverage decision in a migration — pick "rehost" for everything and you have just moved your problems to a more expensive location. Here are the six strategies with real on-prem examples and how to choose.
The 6 R’s (an evolution of Gartner’s original 5 R’s) are the shared language of both the AWS and Azure migration methodologies. Assign one to every workload during assessment; the mix tells you the shape, cost, and risk of the whole program.
Rehost
Lift & shiftWhen: Tight deadline, legacy app you can’t change, or a datacenter exit clock.
Example: A vendor appliance VM you can’t modify → moved as-is to an Azure/EC2 VM of equivalent size.
Fastest and lowest-risk, but you inherit the same inefficiencies and get the least cloud benefit.
Replatform
Lift & optimizeWhen: A component has an obvious managed equivalent that removes ops burden.
Example: On-prem SQL Server → Azure SQL Managed Instance / Amazon RDS / Cloud SQL; self-managed Redis → a managed cache.
Modest effort, big operational payoff (patching, backups, HA handled). The default choice for most workloads.
Refactor
Re-architectWhen: A strategic app that needs scale, agility, or cloud-native features the monolith can’t give.
Example: A monolithic order service → containers on AKS/EKS/GKE, or event-driven functions with a managed queue.
Highest effort and risk, highest long-term reward. Reserve for the workloads that matter most.
Repurchase
Drop & shopWhen: A commodity capability where a SaaS product beats running it yourself.
Example: Self-hosted email, wiki, CRM, or CI server → the SaaS equivalent.
Removes the workload from your migration entirely — but watch data export and integration.
Retire
DecommissionWhen: Discovery reveals servers nobody uses (there are always more than you think).
Example: That "temporary" 2019 reporting box still burning power. Confirm zero traffic, then kill it.
Pure savings. Typically 10–20% of an estate can simply be switched off.
Retain
Keep for nowWhen: Latency, data-residency/compliance, or a pending business decision blocks the move.
Example: A factory-floor system with hard local latency needs, or an app awaiting a replacement project.
Legitimate — but "retain" should have a review date, not be a permanent excuse.
How to choose, quickly
A rough decision order that works for most workloads:
- Is anyone actually using it? No → Retire.
- Is there a SaaS product that replaces it? Yes → Repurchase.
- Does latency/compliance force it to stay local right now? Yes → Retain (with a review date).
- Does a component have a managed equivalent? Yes → Replatform.
- Is it strategic enough to justify re-architecting? Yes → Refactor.
- Otherwise → Rehost, and optimize later.
From classification to a real target
A classification is only useful if it turns into an architecture. Once you’ve tagged a workload "replatform," you still have to decide what it replatforms to andhowit wires into networking and identity. This is where a visual designer earns its keep: in CloudForge you can take a "replatform" decision — say, SQL Server to a managed database — and immediately draw the target on the canvas, or ask Vani to propose it, then generate the Terraform. The 6 R’s tell you the strategy; the design and generated IaC make it buildable.
The 6 R’s sit inside a larger flow — see the full on-prem to cloud migration playbook for discovery, cost modeling, and wave planning around them.