Every cloud migration deck I've seen opens with the same slide: a tidy chart of the "6 Rs" and a promise that the team will pick the right one for each workload. Six months later, the same team has rehosted everything, called it a transformation, and is quietly paying more than they did on-prem. The framework wasn't wrong. The decision-making was.
Rehost, replatform, rebuild — these aren't a menu you order from once. They're bets, each with a different payback curve. The mistake is treating the choice as technical when it's really about time, money, and how long you can afford to wait for the business to notice.
The three paths, minus the marketing
Strip away the vendor gloss and the differences are blunt.
- Rehost (lift-and-shift): Move the workload as-is onto cloud infrastructure. VMs become VMs. Fast, low-risk, and it changes almost nothing about how the app runs — including the parts that were already hurting you. You get cloud billing and a new set of problems, not cloud benefits.
- Replatform (lift-tinker-shift): Keep the core architecture but swap out the pieces that punish you in the cloud. Move a self-managed database to a managed service. Containerize the app. Push static assets to object storage. Modest effort, real operational wins.
- Rebuild (refactor): Re-architect the workload for how the cloud actually works — decompose the monolith, go event-driven, adopt managed and serverless components. Highest cost, highest risk, and the only path that unlocks the elasticity people bought the cloud for.
Rehosting buys you time. Rebuilding buys you capability. Confusing the two is how migration budgets die.
Why "rehost everything" feels safe and usually isn't
Lift-and-shift is seductive because it's measurable. You can put a date on it, the risk is contained, and nobody has to rewrite code. For a data-center exit with a hard lease deadline, it's often the correct opening move — get out of the building first, optimize later.
The trap is that "later" never gets scheduled. A rehosted app on an always-on VM has none of the cost controls the cloud is famous for. You're renting a fixed box by the hour instead of owning it outright, and in my engagements I've routinely seen rehosted workloads land 20–40% above their on-prem run rate in the first year. The cloud didn't fail. Nobody re-architected anything, so nothing got cheaper — the meter just started running.
Rehost with intent, or don't rehost. If it's a bridge, name the second step and put it on a roadmap with an owner. If there's no second step, you've bought a more expensive version of your old data center.
A decision test you can run on Monday
Skip the scoring matrix with forty weighted columns. For each significant workload, ask four questions and let the answers push you toward a path.
1. What's the deadline, and is it real?
A hard exit date (lease ending, data center closing, license expiring) pulls hard toward rehost. Time you don't have is the most honest constraint there is.
2. Is this workload a competitive advantage or plumbing?
Your differentiator — the thing customers actually pay for — deserves rebuild when the current architecture caps its growth. Commodity internal tooling almost never does. Don't rebuild your expense-approval app; nobody was going to give you a medal for it.
3. What's the specific pain, and where does it live?
If the app is fine but the self-managed database eats your weekends, that's a replatform — targeted surgery, not a rewrite. Match the size of the fix to the size of the problem.
4. Can the team operate what you're proposing?
A serverless rebuild handed to a team that's never run distributed systems isn't a migration, it's a future incident. Capability is a real input, not an excuse. If the skills aren't there, either build them first or pick a path the team can actually run.
Sequence beats strategy
The best migrations I've been part of weren't the ones with the cleanest framework. They were the ones with the smartest order. Rehost the workloads that are blocking your exit. Replatform the two or three systems bleeding you operationally. Rebuild the one thing that's genuinely holding the business back — and only that one, until it's done.
Mixing paths isn't indecision; it's portfolio thinking. Different workloads have different economics, so they earn different treatment. The teams that struggle are the ones that pick one R and apply it to everything, then act surprised when the plumbing costs as much to rebuild as the crown jewels.
Where to start
Pull your top ten workloads by cost and by business criticality. For each, write down the deadline, the pain, and whether the team can operate the target state. You'll find most of them sort themselves into rehost or replatform in an afternoon — and one or two genuinely deserve a rebuild. That shortlist, not the framework, is your strategy.
Before you move a single workload, ask the harder question: what does this migration need to make cheaper, faster, or more resilient — and would the path you've chosen actually deliver it?