Lift And Shift vs Replatforming
Two cloud migration strategies, two very different bills. Lift and shift drags your app to the cloud unchanged; replatforming refactors it to actually use the cloud. Here's which one to pick and when.
The short answer
Replatforming over Lift And Shift for most cases. Lift and shift moves your problems to a more expensive zip code.
- Pick Lift And Shift if have a hard deadline (data-center lease expiry, acquisition), a frozen legacy stack nobody understands, and you just need it OFF the old hardware now — then re-architect later
- Pick Replatforming if staying in the cloud for years and want the bill to go DOWN, not up. Managed databases, container orchestration, and autoscaling only pay off if you actually adopt them
- Also consider: Most real migrations are a blend: lift-and-shift the untouchable monolith, replatform the database and stateless tiers. Pure strategies are for slide decks.
— Nice Pick, opinionated tool recommendations
What they actually are
Lift and shift (rehosting) means picking up your application exactly as it runs on-prem and dropping it onto cloud VMs. Same OS, same app server, same self-managed database — just someone else's hardware underneath. Replatforming is the '6 R's' middle child: you keep the core architecture but swap pieces for managed equivalents. Self-managed MySQL becomes RDS or Aurora. A hand-rolled cron box becomes a managed scheduler. App servers move into containers behind an autoscaling group. Neither is a full rewrite — that's replatforming's overachieving cousin, refactoring. The honest difference: lift and shift changes WHERE your app runs and nothing else. Replatforming changes HOW it runs just enough to stop paying humans to babysit infrastructure the cloud will babysit for free. One is a moving truck. The other is a moving truck plus a renovation. Pretending they cost the same is how migration budgets detonate.
Cost and the lie of the quick win
Lift and shift sells itself on speed, and it delivers — for about a quarter. Then the invoice arrives. Always-on VMs sized for peak load run 24/7 at on-prem utilization, which in the cloud means you're renting a Ferrari to sit in traffic. You pay premium rates for idle capacity, self-managed patching, and licensing you could have shed. Replatforming front-loads the pain: refactoring to RDS, autoscaling, and managed queues costs real engineering weeks. But Aurora scales storage automatically, autoscaling groups kill idle nodes, and you stop paying three engineers to manage a database AWS will manage for a fraction. The crossover is brutal and predictable — lift and shift is cheaper at month one and more expensive at month twelve. If you'll live in the cloud for years, the 'fast' option is the one that quietly bleeds you. Speed is not savings.
Risk, lock-in, and the things that bite
Lift and shift's whole pitch is low risk: same binaries, same config, so if it worked before it works now. Mostly true — until you hit network latency between tiers that assumed a LAN, or storage IOPS that cost extra to match your old SAN. Its real downside isn't blowups, it's stagnation: you've spent the migration budget and gained nothing architecturally. Replatforming carries genuine execution risk — every swapped component is a chance to break behavior, and managed services impose THEIR opinions on YOUR app. It also deepens cloud lock-in: lean on Aurora, SQS, and proprietary autoscaling and leaving gets expensive. That's the trade. Lift and shift keeps you portable and mediocre. Replatforming chains you to one cloud but makes that cloud actually worth it. Choosing portability you'll never use over economics you'll feel monthly is sentimentality, not strategy.
The decisive call
Pick replatforming. The cloud is not a colocation facility with better marketing — its entire value is the managed services and elastic scaling that lift and shift refuses to touch. If you rehost and stop, you've paid cloud prices for data-center outcomes, and you'll do the replatforming work anyway in eighteen months under worse pressure when the bill spikes. Do it once, do it now. The only honest case for lift and shift is a gun-to-the-head deadline: a lease expiring, a data center closing, an acquisition clock. Then yes, get OFF the old iron first and refactor from a position of safety. That's a sequencing decision, not a strategy. For everyone else — anyone who'll run in the cloud for years — replatforming is the pick because it's the only option that makes the migration pay for itself. 'Move it and we'll optimize later' is where optimization goes to die.
Quick Comparison
| Factor | Lift And Shift | Replatforming |
|---|---|---|
| Time to migrate | Fast — weeks, same binaries and config | Slower — refactoring managed services adds engineering weeks |
| Ongoing cloud bill | Climbs — always-on VMs at on-prem utilization | Drops — autoscaling and managed services cut idle spend |
| Operational burden | Unchanged — you still patch and babysit everything | Offloaded — managed DB, queues, scaling run themselves |
| Execution risk | Low — if it ran before, it runs now | Higher — every swapped component can break behavior |
| Long-term payoff | None — architecturally stagnant, work deferred not avoided | Real — actually banks the cloud's economics |
The Verdict
Use Lift And Shift if: You have a hard deadline (data-center lease expiry, acquisition), a frozen legacy stack nobody understands, and you just need it OFF the old hardware now — then re-architect later.
Use Replatforming if: You're staying in the cloud for years and want the bill to go DOWN, not up. Managed databases, container orchestration, and autoscaling only pay off if you actually adopt them.
Consider: Most real migrations are a blend: lift-and-shift the untouchable monolith, replatform the database and stateless tiers. Pure strategies are for slide decks.
Lift and shift moves your problems to a more expensive zip code. Replatforming is the only path that actually banks the cloud's economics — managed services, autoscaling, and a bill that drops instead of climbing. The migration costs more up front and pays you back every month after.
Related Comparisons
Disagree? nice@nicepick.dev