Key takeaways
Lift-and-shift moves the application and keeps the problem. The legacy design, the technical debt, and the inefficiencies all arrive in the cloud intact, now running on metered infrastructure.
The waste is visible at market scale. Organizations report 29% of cloud spend wasted (Flexera 2026, 753 cloud decision-makers), and US technical debt stands at an estimated $1.52 trillion (CISQ). Rehosting carries that debt across, unpriced.
Lift-and-shift is sometimes right: commodity apps, a datacenter exit deadline, or phase one of a funded plan. The trap is when "phase two" is a promise with no budget line.
The alternative is a decision per application: keep, re-platform, replace, or retire, made against a real baseline before anything moves.
Why does everyone default to lift-and-shift?
Because every pressure in the room points at it. The mandate says "get to the cloud in 12 months," and rehosting is the only approach that plausibly fits the date. The vendor's quote is lowest for lift-and-shift, because moving virtual machines is the work they can estimate without understanding your applications. The business case counts the datacenter you exit and skips the cloud bill you inherit. And AI-accelerated tooling has made the move itself faster than ever, which makes the default even more tempting, because the one thing speed cannot do is make the destination right.
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, after rehosting, a 20-year-old monolith sized for peak load on infrastructure you rent by the hour. It cannot scale down at night, cannot scale out under load, and cannot use the managed services that make cloud economics work. Elasticity is what you moved to the cloud to buy. A rehosted legacy app cannot consume it.
The market-level evidence: 29% of cloud spend is wasted by organizations' own estimate (Flexera 2026), and the figure just rose for the first time in five years. A large share of that waste is exactly this, workloads that were moved rather than rethought, idling at sizes chosen for a datacenter that no longer exists.
The technical debt travels with the app
CISQ puts accumulated US technical debt at roughly $1.52 trillion, inside a $2.41 trillion annual cost of poor software quality. Lift-and-shift does not reduce that liability by a dollar. It relocates it to premium infrastructure and adds a new dependency layer on top. Every workaround, every undocumented integration, every end-of-life component boards the plane with the application, which is why we covered the pre-migration assessment as the step that prices this debt before you inherit it at cloud rates.
The second migration is the one nobody budgets
The quiet cost of rehosting is that the modernization still has to happen. Rehost now, and the re-architecture work waits for you in the cloud, except now it competes with a visible monthly bill, a business that considers the migration finished, and a team that has moved on. Large IT projects already run 45% over budget and deliver 56% less value than planned (McKinsey and Oxford, 5,400+ projects). Splitting one migration into two unplanned ones is how those numbers get worse. Some organizations conclude the move itself was the mistake and start pulling workloads back on-prem, which is two migrations spent to end up where they began.
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, well understood, and near the end of its life anyway. Moving it cheaply beats improving it.
A hard deadline forces it: a datacenter lease expiring, a divestiture, an exit from unsupported hardware. Speed legitimately outranks design, for now.
It is phase one of a funded plan: rehost to stop the bleeding, then re-platform on a schedule that has a budget line, an owner, and a date. Funded is the operative word.
The trap is none of those. 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 is the part of the plan that was cut before the plan was approved.
The decision that replaces the default: keep, re-platform, replace, retire
The alternative to one strategy for 200 applications is one decision per application, made against a real baseline. Four options, applied ruthlessly:
The commodity apps above. Move them cheaply, spend nothing more on them.
Apps with real business life left, where targeted changes, managed databases, containers, autoscaling, unlock cloud economics without a rewrite.
Apps whose job a SaaS product or a rebuild now does better than the accumulated patchwork. The assessment often reveals the "simple re-platform" was a replace all along.
The portfolio's dead weight. Most enterprise portfolios carry applications nobody will claim; every one retired is a migration you never pay for.
Sorting a portfolio this way is exactly the work the pre-migration assessment exists to do, and it is why an assessed migration quotes differently from a rehost-everything one. The rehost quote is cheaper the way skipping the inspection makes a house cheaper.
The contrast: relocation vs. migration with a decision behind it
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 inherited, sized for the old datacenter
Workloads sized for elasticity from day one
Technical debt arrives intact, now on metered infra
Debt priced, and paid down or retired in the plan
Modernization deferred to an unfunded phase two
Modernization scoped where it pays, skipped where it does not
"Migration complete" then the invoice conversation
Migration complete, and the run cost was the plan
What we see in the field
Across our migration pods, the portfolios that produce the savings clients quote back to us were triaged first. On our largest migration engagements, 300+ applications moved, the results, infrastructure cost down 35%, deployment speed up 50%, unplanned downtime down 60%, did not come from moving faster than the last vendor. They came from the sort: a meaningful slice of the portfolio retired outright before anything moved, commodity apps rehosted cheaply and left alone, and the modernization budget concentrated on the applications where elasticity and managed services actually pay rent.
The pattern on the other side is just as consistent. The clients who arrive mid-migration with a runaway cloud bill are almost always holding a completed rehost, a portfolio that moved on schedule and now costs more than the datacenter did.
Executive takeaway
Run the decision through the three things you translate everything into.
The triage adds two to four weeks up front. The rehost default defers months of modernization into a second, unfunded project that arrives after the migration is declared done, on someone else's timeline.
The market wastes 29% of cloud spend, and rehosted legacy is a leading reason. A per-application sort is how migrations produce a smaller bill than the datacenter, instead of a bigger one with better branding.
A rehost-everything quote is cheap because it prices the move, not the outcome. When the invoice lands, the vendor was paid for exactly what it promised, and the gap between "migrated" and "modernized" belongs to whoever signed. The per-app decision, made against a baseline, is what makes the number you present to the board one that holds.
AI made the move fast. Deciding what deserves to move is still the hard part, and that decision is what a 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 cannot exploit: no elasticity, no managed services, sized for a datacenter that no longer exists. 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 where cheap movement beats improvement, hard deadlines like a datacenter exit where speed legitimately wins, and phase one of a modernization plan that has a real budget and date for phase two. Absent one of those, rehosting is deferral priced as strategy.
What is the alternative to lift-and-shift?
A decision per application: keep (rehost), re-platform, replace, or retire, made against a dependency map and technical-debt baseline from a pre-migration assessment. Retiring dead applications and concentrating modernization where it pays is what turns a migration into a cost reduction.
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 or using cloud-native services. Organizations self-report 29% of cloud spend wasted (Flexera 2026), 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. 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.
Already mid-migration and watching it drift? The companion guide covers the rescue: Anatomy of a Stalled Migration.
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.
By NorthStar Group.
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 See also Flexera press release, "Flexera Finds Cloud Value is Rising While AI Waste Grows." 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
"Lift-and-shift locks in your inefficiencies for another five to ten years" and "a relocation exercise, not a transformation": practitioner consensus from cloud-migration industry analyses, compiled June 2026. Directional framing, not a survey statistic.