Lift-and-Shift vs Replatform vs Refactor: The Real Tradeoffs
On this page
- The three paths, defined precisely
- The comparison table
- What each path really costs: one app, three ways
- The decision framework
- The failure modes of each path
- FAQ
- What is the difference between lift-and-shift, replatform, and refactor?
- Is lift-and-shift a bad strategy?
- When is refactoring worth the cost?
- Can we lift-and-shift now and refactor later?
- Does replatforming to a managed database lock us in?
“Should we just lift it, or fix it while we’re at it?” is the question that stalls more migration planning meetings than any other. The answer is different per application, and it’s answerable with a table, not a debate.
The three paths, defined precisely
These are the three “move it and keep it” options from the 6 Rs (retire, retain, and repurchase being the others):
- Lift-and-shift (rehost): the application moves to cloud VMs as-is. Same OS, same stack, same architecture. Tools like AWS MGN or Azure Migrate replicate running servers block-by-block; the app doesn’t know it moved.
- Replatform (“lift-tinker-shift”): the application code stays put, but one or two components upgrade in transit, self-managed Postgres to RDS, a hand-built HAProxy to a managed load balancer, local disk files to object storage.
- Refactor (re-architect): the application itself changes, decomposed into services, containerized, given autoscaling, possibly rebuilt on serverless. The only path that changes what the application can do.
The comparison table
For a typical mid-size business application (a web app, an app server, a database, call it 4-6 servers):
| Lift-and-shift | Replatform | Refactor | |
|---|---|---|---|
| Migration cost | $5k-$25k | $15k-$60k | $100k-$500k+ |
| Timeline per app | Days-3 weeks | 3-8 weeks | 3-12 months |
| Migration risk | Low, app unchanged | Medium, swapped components need testing | High, it’s a rebuild |
| Downtime at cutover | Minutes-hours | Minutes-hours | Can be near-zero (built new alongside old) |
| Run cost, day 1 | Highest, inherits old sizing | Medium | Lowest |
| Run cost, after optimization | −25-40% via right-sizing | Low | Lowest, scales with actual load |
| Ops burden after | Same as before (you still patch everything) | Reduced, managed components off your pager | Lowest, but requires new skills |
| Time-to-value | Immediate (datacenter exit achieved) | Fast | Slow, value arrives when the rebuild ships |
| New capabilities gained | None | Reliability of managed services | Elastic scale, deploy velocity, resilience |
| Skills required | What you have now | Modest, managed-service literacy | Significant, containers/K8s or serverless, CI/CD, distributed systems |
Ranges are wide because applications are, but the ratios hold almost everywhere: replatform ≈ 1.5-2.5x rehost effort; refactor ≈ 5-10x.
What each path really costs: one app, three ways
Take a concrete case: an internal order-management app. Two web servers, one job server, one 500 GB SQL Server database. On-prem cost allocation: ~$3,800/month.
Path A, lift-and-shift. Four VMs replicated up, cut over on a Saturday evening. Migration: ~$12k of effort. Day-1 cloud bill: ~$3,400/month, because the VMs were sized for a 2019 peak. After a right-sizing pass at day 60 (halving two oversized boxes): ~$2,300/month. Team still patches Windows and babysits SQL Server backups.
Path B, replatform. Same three app VMs, but the database moves to a managed SQL instance via DMS-style replication. Migration: ~$28k (schema compatibility checks, connection-string changes, a replication rehearsal). Bill: ~$2,600/month, the managed database costs more than a raw VM, but backups, patching, and failover left the team’s calendar permanently. Two years of not paging a DBA at 3 a.m. quietly repays the delta.
Path C, refactor. App rebuilt as containers with autoscaling and a managed queue for the job workload. Migration: ~$180k over 7 months. Bill: ~$1,400/month, scaling down on weekends to near-idle. Worth it? For this app, 200 internal users, flat load, no release pressure, plainly not. The $150k+ premium over Path B never pays back. For a customer-facing app with 10x quarter-end spikes and weekly releases, the same math flips.
That’s the whole discipline: the paths aren’t better or worse, they’re priced for different problems.
The decision framework
Answer four questions per application, in order:
1. Is there a hard deadline? Lease expiry, hardware end-of-life, an exit from a colo contract. If yes and it’s close: lift-and-shift now, revisit later. Deadlines beat elegance.
2. Does the app have a problem that architecture causes? Can’t absorb traffic spikes; infra cost grows linearly with usage; releases take weeks because everything is coupled. If yes → refactor is on the table (proceed to question 4). If no → refactor is off the table, full stop. Stable apps don’t repay rebuilds.
3. Is the operational pain concentrated in a swappable component? If your on-call log is dominated by database, load-balancer, or storage incidents, replatform exactly those components and rehost the rest. This is the highest-ROI move in most migrations.
4. Does the refactor math clear the bar? Estimate the rebuild cost honestly (then add 30%, everyone underestimates). Estimate annual benefit: run-cost savings + outage cost avoided + value of faster releases. If annual benefit < one-third of build cost, the payback stretches past 3 years and past most CFOs’ patience. Rehost or replatform instead, and put a revisit date on the calendar.
A useful heuristic for the portfolio as a whole: lift-and-shift the majority, replatform the databases, refactor the one or two apps that earn it. If you’re planning to refactor more than ~15% of your portfolio during the migration itself, your timeline is fiction. (If you’re considering containerizing apps before the move to make them portable, that has its own tradeoffs.)
The failure modes of each path
Every path has a characteristic way of going wrong. Know yours:
- Lift-and-shift’s failure mode is permanence. “We’ll optimize later” becomes never; the estate runs 40% oversized for years and the CFO concludes the cloud was a ripoff. Fix: put the right-sizing pass and the commitment purchases on the calendar before cutover, with an owner.
- Replatform’s failure mode is the 90%-compatible component. The managed database is almost identical, except the one extension, collation, or maintenance-window behavior your app depended on. Fix: run the full test suite against the managed service before cutover, not after. Budget for one ugly surprise per component.
- Refactor’s failure mode is the two-front war. Re-architecting while migrating means every bug has two suspects (the move? the rewrite?) and the project stalls at 80% for months. Fix: move first, refactor from inside the cloud, one component at a time, with the old path still running.
FAQ
What is the difference between lift-and-shift, replatform, and refactor?
Lift-and-shift (rehost) moves an application to cloud VMs unchanged. Replatform moves it with targeted component upgrades, most often swapping a self-managed database for a managed one like RDS, without touching application architecture. Refactor re-architects the application itself for cloud-native services: containers, autoscaling, managed queues, serverless. Effort, cost, and payoff all rise in that order.
Is lift-and-shift a bad strategy?
No, it’s the right strategy for stable applications and deadline-driven migrations, and it’s how teams learn cloud operations on familiar workloads. It becomes a bad strategy only when it’s treated as the end state: unoptimized rehosted estates typically waste 30-50% of their compute spend. Plan a right-sizing pass 60-90 days after cutover and it’s a perfectly sound first move.
When is refactoring worth the cost?
When the application has a problem re-architecture actually solves: traffic spikes it can’t absorb, infrastructure cost that scales linearly with load, or a release cadence too slow for the business. As a rule of thumb, the projected annual benefit (run-cost savings plus revenue protected) should exceed roughly a third of the refactor cost, or the payback period stretches past the point anyone will defend it.
Can we lift-and-shift now and refactor later?
Yes, and it’s usually the best sequence. Moving first gets you off the deadline, gives you real usage data, and lets you refactor incrementally, one component at a time, from inside the cloud. The risk to manage is “later” never coming: put the refactor decision on a calendar (e.g., 6 months post-migration) with named owners, or the temporary state becomes permanent.
Does replatforming to a managed database lock us in?
Less than people fear, if you stay on open engines. RDS PostgreSQL is still PostgreSQL, your schema, queries, and drivers work anywhere Postgres runs. Lock-in gets real when you adopt proprietary engines (Aurora-specific features, DynamoDB, Cosmos DB) or wire application logic to provider-only services. Choose managed open-source engines and the exit door stays open.
If you’re weighing these paths for a specific application, or a specific deadline, a second opinion is cheap insurance. Talk to a Webisoft cloud engineer: bring your app list, and we’ll tell you which path each one actually needs, including the ones where the honest answer is “don’t touch it.”
Frequently asked questions
What is the difference between lift-and-shift, replatform, and refactor?
Lift-and-shift (rehost) moves an application to cloud VMs unchanged. Replatform moves it with targeted component upgrades, most often swapping a self-managed database for a managed one like RDS, without touching application architecture. Refactor re-architects the application itself for cloud-native services: containers, autoscaling, managed queues, serverless. Effort, cost, and payoff all rise in that order.
Is lift-and-shift a bad strategy?
No, it's the right strategy for stable applications and deadline-driven migrations, and it's how teams learn cloud operations on familiar workloads. It becomes a bad strategy only when it's treated as the end state: unoptimized rehosted estates typically waste 30-50% of their compute spend. Plan a right-sizing pass 60-90 days after cutover and it's a perfectly sound first move.
When is refactoring worth the cost?
When the application has a problem re-architecture actually solves: traffic spikes it can't absorb, infrastructure cost that scales linearly with load, or a release cadence too slow for the business. As a rule of thumb, the projected annual benefit (run-cost savings plus revenue protected) should exceed roughly a third of the refactor cost, or the payback period stretches past the point anyone will defend it.
Can we lift-and-shift now and refactor later?
Yes, and it's usually the best sequence. Moving first gets you off the deadline, gives you real usage data, and lets you refactor incrementally, one component at a time, from inside the cloud. The risk to manage is 'later' never coming: put the refactor decision on a calendar (e.g., 6 months post-migration) with named owners, or the temporary state becomes permanent.
Does replatforming to a managed database lock us in?
Less than people fear, if you stay on open engines. RDS PostgreSQL is still PostgreSQL, your schema, queries, and drivers work anywhere Postgres runs. Lock-in gets real when you adopt proprietary engines (Aurora-specific features, DynamoDB, Cosmos DB) or wire application logic to provider-only services. Choose managed open-source engines and the exit door stays open.