Lift and shift versus refactor is a trade between speed now and run cost later. Lift and shift moves a workload to the cloud unchanged: fast, low engineering effort, low migration risk, but it carries your on premises sizing, idle headroom, and licensed databases straight onto cloud meters, so it almost always runs more expensively than it should. Refactoring redesigns the workload to use managed services, autoscaling, and cloud native data and compute, which lowers steady run cost but spends engineering time and adds project risk. Over a multi year horizon the refactored estate is normally the cheaper one to operate. The practical answer for most enterprises is not to choose one, it is to sequence them: lift and shift where a deadline demands speed, then treat the months after migration as a funded optimization window, so the cloud bill actually falls instead of freezing your old inefficiency at cloud prices.
Here is how the two paths compare, when each pays, and how to sequence them.
How do the two paths compare on cost?
| Dimension | Lift and shift | Refactor |
|---|---|---|
| Time to migrate | Fast, weeks to months | Slow, months to quarters per workload |
| Engineering effort | Low | High |
| Migration risk | Low, the workload is unchanged | Higher, behaviour can change |
| Steady run cost | High, carries idle and licensing | Lower, managed and elastic |
| Best when | A deadline forces speed | The workload is strategic and long lived |
The asymmetry is the whole point: lift and shift wins on the cost of moving, refactor wins on the cost of running. Which dominates depends on how long the workload will live and how soon you can fund the engineering.
When does lift and shift actually pay?
Lift and shift pays when speed has a price. A datacenter exit deadline, a lease expiry, a hardware refresh you want to avoid, or an acquisition that has to be integrated fast all make the calendar the binding constraint, and a clean fast migration beats a slow optimal one. It also pays as a deliberate first step for a stable workload you intend to optimize in place afterwards, because moving first and tuning second can be lower risk than redesigning during a migration. The mistake is not choosing lift and shift; it is choosing it and then stopping, leaving an estate that runs your old sizing and your licensed databases on cloud meters indefinitely.
When is refactoring worth the engineering?
Refactoring is worth it where the workload is strategic, long lived, and currently expensive to run for structural reasons a resize cannot fix: a monolith that cannot scale down, a database whose license dominates the bill, a batch system that would be far cheaper as serverless or spot. Here the up front engineering buys a permanently lower run rate, and the multi year saving outweighs the project cost. The discipline is to refactor selectively, target the workloads where the run cost is high and the architecture is the cause, rather than rewriting everything because cloud native sounds correct. A refactor with no modelled run cost reduction is just risk without return.
A worked example
A European SaaS company had to vacate a datacenter on a fixed date, so it lift and shifted its estate unchanged to hit the deadline, and its cloud bill landed well above the old hosting cost, exactly as expected for an unoptimized move. The difference from a typical failure was that the optimization window was funded before the migration started. In the months after the move, right sizing removed the on premises idle headroom, two heavy workloads were refactored to managed and autoscaling services where the run cost justified the effort, and licensed databases were addressed. The estate ended materially below both the lift and shift bill and the original datacenter cost, with the deadline met and the optimization treated as a planned second phase rather than a someday hope. Figures are verified against billing data and anonymised.
Frequently asked questions
Is lift and shift cheaper than refactoring?
When does lift and shift make sense?
How do you avoid a lift and shift bill that never improves?
Sequence migration so the bill actually falls
We help enterprises decide what to lift and shift, what to refactor, and how to fund the optimization window, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the cloud cost optimization playbook, read the cross cloud cost optimization guide, and pair it with building a migration business case that holds.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.