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:

Keep (rehost)

The commodity apps. Move them cheaply, spend nothing more on them.

Re-platform

Apps with business life left, where targeted changes (managed databases, containers, autoscaling) unlock cloud economics without a rewrite.

Replace

Apps whose job a SaaS product or rebuild now does better.

Retire

The dead weight. Every application retired is a migration you never pay for.

✕ Rehost everything

One strategy for the whole portfolio

✓ Decide per application

Keep, re-platform, replace, or retire, per app

✕ Rehost everything

Quoted from the server count

✓ Decide per application

Quoted from a dependency and debt baseline

✕ Rehost everything

Cloud bill sized for the old datacenter

✓ Decide per application

Workloads sized for elasticity from day one

✕ Rehost everything

Modernization deferred to an unfunded phase two

✓ Decide per application

Modernization scoped where it pays

✕ Rehost everything

"Migration complete," then the invoice conversation

✓ Decide per application

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

Your time

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.

Your money

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.

Your risk

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

Keep Reading

Scroll to Top