Lift and Shift vs Replatforming: The Migration Verdict
Two cloud migration strategies, one decision: move your app as-is or modernize on the way in. Here's which one actually pays off.
The short answer
Replatforming over Lift And Shift for most cases. Lift and shift gets you off the old data center fast, then leaves you running the same expensive, unmanaged mess on someone else's hardware with a bigger bill.
- Pick Lift And Shift if have a hard data-center exit date, a lease expiring, or a DR fire — and you need the app off-prem this quarter regardless of cost
- Pick Replatforming The Migration Verdict if control the timeline and want the migration to actually lower your run-rate: swap self-managed DBs for RDS, VMs for containers, cron boxes for managed schedulers
- Also consider: Lift and shift as phase one, replatforming as a deliberate phase two — but only if you write the phase-two date in blood, because 'we'll modernize later' is where migrations go to die.
— Nice Pick, opinionated tool recommendations
What they actually are
Lift and shift (rehosting) moves your application to the cloud unchanged — same OS, same self-managed database, same architecture, now running on EC2 or GCE instead of a rack you own. Nothing about the app knows it moved. Replatforming (the 'lift, tinker, and shift') keeps the core code intact but swaps infrastructure pieces for managed equivalents on the way in: self-hosted Postgres becomes RDS, a VM fleet becomes ECS or GKE, your homegrown queue becomes SQS. The app changes a little; the operational burden changes a lot. Neither is refactoring — that's a third, far more expensive animal where you rewrite the app to be cloud-native. The honest framing: lift and shift changes your address, replatforming changes your bills and your pager load. Most teams conflate the two and then wonder why the cloud got expensive.
Cost: the lie of the easy move
Lift and shift is sold as cheap because the migration project is cheap. The running cost is where it knifes you. You provisioned on-prem hardware for peak load and never gave it back, so you migrate that same over-provisioned footprint to instances that bill by the hour, 24/7, peak-sized. Now you're paying premium cloud rates for idle capacity you used to own outright. Replatforming front-loads more engineering — you're rearchitecting the data layer, wiring autoscaling, learning a managed service — but it lets the bill follow actual usage. Managed databases kill the DBA salary line. Autoscaling kills the idle-instance line. The crossover is brutal: a lift-and-shift estate routinely costs more in cloud than it did on-prem, and finance notices by month three. Replatforming is the only path where 'we moved to the cloud to save money' isn't a punchline.
Speed and risk tradeoff
Lift and shift wins on calendar, full stop. Minimal code changes mean fewer surprises, a tighter blast radius, and a rollback that's basically 'point DNS back.' If your data center lease ends in 90 days, this is the only sane answer — you cannot replatform a fleet of services under that gun without breaking something load-bearing. Replatforming is slower and riskier per service: swapping to RDS means migrating data, revalidating connection pooling, and discovering which of your app's assumptions about the database were never documented. Containerizing surfaces every hardcoded path and stateful local-disk write your team pretended didn't exist. The risk is real but bounded and visible — you find the rot during migration instead of inheriting it. Lift and shift defers that reckoning, it doesn't cancel it. You will pay the modernization tax eventually; the only question is whether you pay it deliberately or during an outage.
Where each one earns its keep
Lift and shift earns it under duress: data-center exits, acquisitions forcing consolidation, disaster-recovery scrambles, or legacy systems so brittle that touching them is more dangerous than overpaying to run them. For a 15-year-old monolith nobody understands, rehosting unchanged is the responsible cowardice. Replatforming earns it everywhere you have time and want the cloud to actually do something for you. The sweet spot is targeted: don't replatform the whole estate, replatform the expensive and the painful parts. Move the database you're tired of patching to managed. Containerize the service that needs to scale. Leave the stable, cheap stuff alone. The failure mode for replatforming is scope creep into a full rewrite — that's not replatforming anymore, that's a multi-year refactor wearing a migration's name tag. Stay disciplined: same app, better plumbing. That's the win, and it's a real one that lift and shift structurally cannot deliver.
Quick Comparison
| Factor | Lift And Shift | Replatforming The Migration Verdict |
|---|---|---|
| Time to migrate | Fast — minimal code changes, tight blast radius | Slower — data migration and service swaps per component |
| Long-term run cost | Often higher than on-prem — peak-sized footprint billed hourly | Lower — managed services and autoscaling track real usage |
| Operational burden after | Unchanged — you still patch, scale, and babysit everything | Reduced — managed DBs and orchestration offload the toil |
| Migration risk | Low and reversible — point DNS back | Bounded but real — surfaces hidden stateful assumptions |
| Captures the reason you migrated | No — just changes your landlord | Yes — delivers cloud economics and elasticity |
The Verdict
Use Lift And Shift if: You have a hard data-center exit date, a lease expiring, or a DR fire — and you need the app off-prem this quarter regardless of cost.
Use Replatforming The Migration Verdict if: You control the timeline and want the migration to actually lower your run-rate: swap self-managed DBs for RDS, VMs for containers, cron boxes for managed schedulers.
Consider: Lift and shift as phase one, replatforming as a deliberate phase two — but only if you write the phase-two date in blood, because 'we'll modernize later' is where migrations go to die.
Lift And Shift vs Replatforming The Migration Verdict: FAQ
Is Lift And Shift or Replatforming The Migration Verdict better?
Replatforming is the Nice Pick. Lift and shift gets you off the old data center fast, then leaves you running the same expensive, unmanaged mess on someone else's hardware with a bigger bill. Replatforming captures the actual reason you migrated — managed services, autoscaling, and lower run-cost — without the suicide mission of a full rewrite. It's the only one of the two that improves your economics instead of just changing your landlord.
When should you use Lift And Shift?
You have a hard data-center exit date, a lease expiring, or a DR fire — and you need the app off-prem this quarter regardless of cost.
When should you use Replatforming The Migration Verdict?
You control the timeline and want the migration to actually lower your run-rate: swap self-managed DBs for RDS, VMs for containers, cron boxes for managed schedulers.
What's the main difference between Lift And Shift and Replatforming The Migration Verdict?
Two cloud migration strategies, one decision: move your app as-is or modernize on the way in. Here's which one actually pays off.
How do Lift And Shift and Replatforming The Migration Verdict compare on time to migrate?
Lift And Shift: Fast — minimal code changes, tight blast radius. Replatforming The Migration Verdict: Slower — data migration and service swaps per component. Lift And Shift wins here.
Are there alternatives to consider beyond Lift And Shift and Replatforming The Migration Verdict?
Lift and shift as phase one, replatforming as a deliberate phase two — but only if you write the phase-two date in blood, because 'we'll modernize later' is where migrations go to die.
Lift and shift gets you off the old data center fast, then leaves you running the same expensive, unmanaged mess on someone else's hardware with a bigger bill. Replatforming captures the actual reason you migrated — managed services, autoscaling, and lower run-cost — without the suicide mission of a full rewrite. It's the only one of the two that improves your economics instead of just changing your landlord.
Related Comparisons
Disagree? nice@nicepick.dev