On this page
Migration isn't one decision, it's hundreds
"We're moving to the cloud" is the start of a conversation, not a plan. A real estate of 200 applications doesn't have one migration strategy, it has up to 200, because the right move for a legacy mainframe app is nothing like the right move for a stateless web service or a database you could replace with a managed offering tomorrow. The teams that fail treat migration as one big lift-and-shift; the teams that succeed sort each workload into the strategy that fits it.
The 6 Rs are the industry-standard framework for that sorting. Each R is a different answer to "what do we do with this specific application?", trading migration effort against the payoff you get on the other side. This article defines all six, lays them out by effort vs payoff, and gives you a way to assign the right R to each workload.
Who this is for
Engineers and architects planning or executing a cloud migration, or studying the framework for an interview or certification. No prior migration experience needed, but knowing the [IaaS/PaaS/SaaS distinction](/blog/iaas-paas-saas-what-you-actually-manage) will make the trade-offs land harder.
The 6 Rs, defined
The 6 Rs are six distinct strategies for what to do with an application when you migrate: rehost, replatform, repurchase, refactor, retire, and retain.
Here's the one-line version of each, before we put numbers to them:
Effort vs payoff: the whole framework in one table
The core trade-off is always the same: the more you change an app, the more cloud-native benefit you unlock, and the more it costs to get there. Two of the six (retire, retain) are about *not* migrating at all, and they're often the most valuable decisions you'll make.
| Strategy | What it means | Effort | Pick it when… |
|---|---|---|---|
| Rehost | Move as-is to cloud VMs ("lift & shift") | Low | You need to exit a datacenter fast; app works fine as-is |
| Replatform | Lift & shift with small cloud optimizations | Low–Medium | A quick win is available (e.g. move DB to a managed service) |
| Repurchase | Drop the app, buy a SaaS equivalent | Low–Medium | A SaaS product does the job better (e.g. self-hosted email → Microsoft 365) |
| Refactor | Re-architect to be cloud-native | High | The app is strategic and current architecture blocks scale/agility |
| Retire | Decommission, turn it off | Very low | Nobody actually uses it (you'll be surprised how many) |
| Retain | Leave it where it is, revisit later | None | Migration isn't worth it yet (compliance, cost, sunset planned) |
Pro tip
Before you migrate anything, run a discovery pass for Retire and Retain. A typical portfolio has 10–20% of apps nobody uses anymore, migrating them is pure wasted effort. The cheapest migration is the one you don't do.
When to reach for each R
Rehost, lift and shift
Pick up the app, drop it onto cloud VMs, change as little as possible. It's the fastest path off your own hardware and the lowest-risk because the app barely changes. The catch: you've moved your problems, not solved them, you get cloud *location* but little cloud *benefit*. It's a legitimate first step when a datacenter lease is expiring and the clock is the priority; you can refactor later.
Replatform, lift, tinker, and shift
Rehost, but take a couple of easy wins on the way: point the app at a managed database instead of a self-run one, put it behind a managed load balancer, containerize it. Modest effort, real operational payoff, you offload some undifferentiated maintenance without a full rewrite. The sweet spot for a lot of workloads.
Repurchase, replace, don't migrate
Sometimes the smartest migration is deleting the app and subscribing to a SaaS product that does the same job better. Self-hosted CRM, wiki, or email servers are classic candidates. You trade control and customization for someone else running it entirely, often the right call for non-differentiating commodity software.
Refactor, rebuild for the cloud
Re-architect the app to be genuinely cloud-native, break a monolith into services, go serverless, adopt managed data stores. This is the highest effort and cost by far, and only worth it for strategic applications where the current architecture is actively holding the business back. Don't refactor a stable app just because cloud-native is fashionable; refactor when the payoff (scale, agility, cost-at-scale) is real and named.
Retire & Retain, the non-migrations
Retire: discovery reveals apps no one uses, duplicate systems, things kept alive "just in case." Turn them off, that's a migration win with zero migration. Retain: some apps shouldn't move yet, a strict compliance requirement, a workload that's cheaper on-prem, or a system slated for sunset within the year. "Not now" is a valid, deliberate answer, not a failure.
Don't default everything to Rehost
Rehost is tempting because it's fast and low-risk, so teams under deadline pressure lift-and-shift everything. You then inherit every inefficiency you had on-prem, plus a cloud bill that's often *higher* than your old hardware because you over-provisioned VMs to match physical servers. Rehost is a fine bridge, just have a plan to optimize afterward, not 'rehost and forget.'
How to actually assign Rs at scale
Across a big portfolio, you don't decide app-by-app from scratch, you run a structured pass.
- 1
Discover the full inventory
You can't migrate what you can't see. Catalog every application, its dependencies, owner, and usage. This step alone surfaces the Retire candidates.
- 2
Score each app on two axes
Business value (how strategic) and migration difficulty (how coupled, how legacy). High-value + high-difficulty apps are your refactor candidates; low-value ones lean toward retire or rehost.
- 3
Assign an R per app
Map each app to its R using the table above. Be honest: most apps are rehost or replatform; refactor is reserved for the strategic few.
- 4
Sequence by risk and dependency
Start with low-risk, low-dependency apps to build momentum and learn your tooling. Migrate tightly-coupled groups together. Save the scary monolith for when the team is warmed up.
Pro tip
Use early, easy rehost/replatform migrations to build organizational muscle, your runbooks, your landing zone, your team's confidence. By the time you reach the hard refactors, you've de-risked everything around them.
Takeaways
The whole article in seven lines
- Migration is a per-application decision, not one company-wide strategy.
- The 6 Rs: rehost, replatform, repurchase, refactor, retire, retain.
- More change = more cloud-native payoff, but more effort and risk. Pick per app.
- Rehost = fast bridge with little benefit; have a plan to optimize after, not 'rehost and forget.'
- Replatform is the sweet spot for many apps; repurchase replaces commodity software with SaaS.
- Refactor only the strategic few where architecture genuinely blocks the business.
- Retire and Retain are real wins, the cheapest migration is the one you don't do.
Where to go next
The 6 Rs tell you *whether* and *how* to move; the next questions are *what you'll manage* afterward and *whether the result is well-architected*.
- IaaS vs PaaS vs SaaS: what you actually manage, the responsibility shift behind replatform and repurchase.
- The Well-Architected Framework, decoded, how to make sure what you migrate is built right.
- The Cloud Engineer path, from fundamentals through migration and governance.
Want to go deeper?
This article covers concepts taught hands-on in the Cloud Engineer and DevOps career paths, with real terminal labs, production scenarios, and structured lessons.