Blog
The Lift-and-Shift Trap: Why Moving Legacy As-Is to the Cloud Just Relocates the Problem
By NorthStar Group · August 24, 2026
Lift-and-shift is the cloud migration strategy that feels fastest, quotes cheapest, and costs the most. You keep paying modern cloud prices to run legacy design for years. Practitioners call it what it is: a relocation, not a transformation. Organizations now report 29% of cloud spend wasted. If you're holding a vendor quote built on rehosting everything, here's when that works, when it traps you, and the per-application decision that separates the two.
Key takeaways
Lift-and-shift moves the app and keeps the problem.
29% of cloud spend is wasted; rehosted legacy is a leading cause.
It's right for commodity apps, hard deadlines, and funded phase-one moves.
The alternative: decide per app. Keep, re-platform, replace, or retire.
Why does everyone default to lift-and-shift?
Because every pressure in the room points at it. The mandate says "cloud in 12 months," and rehosting is the only approach that fits the date. The vendor's quote is lowest, because moving virtual machines is work they can estimate without understanding your applications. And the business case counts the datacenter you exit while skipping the cloud bill you inherit.
The result is a migration that succeeds by every metric on the status report. The apps moved. The date held. Then the first full quarter of cloud invoices arrives, and the conversation changes.
What does relocation actually cost?
You pay cloud prices to run legacy design. A 20-year-old monolith sized for peak load on hardware you owned becomes the same monolith on infrastructure you rent by the hour. It can't scale down at night, can't scale out under load, can't use managed services. Elasticity is what you moved to the cloud to buy, and a rehosted legacy app can't consume it. That's a big share of the 29% waste figure: workloads idling at sizes chosen for a datacenter that no longer exists.
The technical debt travels with the app. Accumulated US technical debt stands at roughly $1.52 trillion. Lift-and-shift doesn't reduce that liability by a dollar. Every workaround, every undocumented integration, every end-of-life component boards the plane with the application. A pre-migration assessment prices this debt before you inherit it at cloud rates.
The second migration is the one nobody budgets. Rehost now, and the modernization still has to happen, except now it competes with a visible monthly bill and a business that considers the migration finished. Large IT projects already run 45% over budget and deliver 56% less value than planned.
When is lift-and-shift the right call?
Honesty about the exceptions is what makes the rule useful. Rehosting earns its place when:
The application is a commodity: stable, low-change, near end-of-life anyway. Moving it cheaply beats improving it.
A hard deadline forces it: a datacenter lease expiring, a divestiture, unsupported hardware. Speed legitimately outranks design, for now.
It's phase one of a funded plan: rehost to stop the bleeding, then re-platform on a schedule with a budget line, an owner, and a date.
The trap is lift-and-shift as the strategy for the whole portfolio, with modernization deferred to a phase two that exists only in the steering-committee deck. A phase two with no budget line was cut before the plan was approved.
The decision that replaces the default
Instead of one strategy for 200 applications, make one decision per application, against a real baseline:
The commodity apps. Move them cheaply, spend nothing more on them.
Apps with business life left, where targeted changes (managed databases, containers, autoscaling) unlock cloud economics without a rewrite.
Apps whose job a SaaS product or rebuild now does better.
The dead weight. Every application retired is a migration you never pay for.
One strategy for the whole portfolio
Keep, re-platform, replace, or retire, per app
Quoted from the server count
Quoted from a dependency and debt baseline
Cloud bill sized for the old datacenter
Workloads sized for elasticity from day one
Modernization deferred to an unfunded phase two
Modernization scoped where it pays
"Migration complete," then the invoice conversation
Migration complete, and the run cost was the plan
What we see in the field
On our largest migration engagements, 300+ applications moved, and the results (infrastructure cost down 35%, deployment speed up 50%, unplanned downtime down 60%) didn't come from moving faster than the last vendor. They came from the sort: a slice of the portfolio retired before anything moved, commodity apps rehosted cheaply, and the modernization budget concentrated where elasticity actually pays rent.
The other side is just as consistent: the clients who arrive with a runaway cloud bill are almost always holding a completed rehost. It moved on schedule, and it costs more than the datacenter did.
What this means for you
The triage adds two to four weeks up front. The rehost default defers months of modernization into a second project you haven't funded yet.
The market wastes 29% of cloud spend, and rehosted legacy is a leading reason. The per-application sort is how your migration produces a smaller bill than the datacenter, not a bigger one with better branding.
A rehost-everything quote is cheap because it prices the move, not the outcome. The gap between "migrated" and "modernized" lands on whoever signed. That's you.
Moving fast is easy now. Deciding what deserves to move is still the hard part, and that decision is what your migration partner should be accountable for.
Frequently asked questions
What is wrong with lift-and-shift cloud migration?
It moves applications without changing their design, so legacy workloads run on metered cloud infrastructure they can't exploit. The technical debt travels intact, and the modernization still has to happen later, usually unfunded.
When does lift-and-shift make sense?
Three cases: commodity applications near end-of-life, hard deadlines like a datacenter exit, and phase one of a modernization plan with a real budget and date for phase two.
Why do cloud costs go up after a lift-and-shift migration?
Rehosted workloads keep their on-prem sizing and design, so they consume premium infrastructure around the clock without scaling down. Organizations self-report 29% of cloud spend wasted, and oversized rehosted workloads are a leading contributor.
Sort the portfolio before you sign the quote
The Cloud Migration Readiness Scorecard covers the baseline checks behind the keep, re-platform, replace, retire sort. No form, ten minutes. If a rehost-everything quote is already on your desk, a 20-minute migration-strategy review gets you an outside read on which applications deserve better than relocation. No obligation.
AI made migration fast. NorthStar makes it accountable.
A per-application plan built on a real baseline, and a vetted, dedicated pod that owns the outcome inside your legacy systems, without the Big-4 bill or the offshore babysitting.
Sources
Flexera, "2026 State of the Cloud Report" (753 cloud decision-makers): self-estimated wasted cloud spend rose to 29%, the first increase after five years of decline. flexera.com
CISQ, "The Cost of Poor Software Quality in the US: A 2022 Report" (Herb Krasner): $2.41 trillion total annual cost, ~$1.52 trillion accumulated technical debt. it-cisq.org
McKinsey and University of Oxford, "Delivering large-scale IT projects on time, on budget, and on value" (5,400+ projects): 45% over budget, 56% less value than predicted. mckinsey.com