Cloud Migration Strategies: The 6 Rs

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.

Note: 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 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:

Migrating apps is like moving house, every box gets a different decision.

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.

The 6 Rs by effort and payoff. The right choice is per-application, there's no universally 'best' R.

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.

Warning: 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.

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.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.