"Lift and shift" is where good cloud migrations go to disappoint you

The story goes like this. Leadership decides the company needs to be "in the cloud." A vendor promises a lift-and-shift — quick, low-risk, we'll just move it. Six months and a real invoice later, you're paying more every month for the exact same problems, now hosted in someone else's building. The reports are still unreadable. The integrations still break on the same Tuesday. Nothing got better; it just got a subscription.

If that's where you are, the frustration is legitimate and the diagnosis is simple. Lift-and-shift moves the box, not the burden. For a legacy ERP it can be a genuinely smart first move or an expensive way to postpone the real work — and which one you got depends entirely on what you did after the truck left.

The vocabulary nobody defined for you

Half the disappointment here comes from a word doing too much work. "Migration" gets used for four very different things, and knowing which one you actually bought changes everything.

Rehost is lift-and-shift: pick the system up as-is and set it down on cloud infrastructure. Same software, same customizations, same warts, new address.

Replatform keeps the application but modernizes some of what's underneath — the database, the runtime, the ops layer — while it moves.

Refactor actually reworks the system to fit a modern architecture. More work, more risk, more payoff.

Repurchase is giving up and buying something new — the full replatforming project, with all the cost and multi-year risk that implies.

Lift-and-shift is the cheapest and fastest of the four because it changes the least. That's its whole appeal, and also the entire source of the disappointment: people buy the cheapest option and are surprised it didn't deliver the benefits of the expensive ones.

When lift-and-shift is the right first move

I want to be fair to it, because it gets dunked on and it's often correct.

If your ERP is running on a server in a closet whose warranty expired during a previous administration, rehosting to the cloud is a legitimate, valuable move. It kills the hardware risk. It gets you out of the data-center business. It buys time and breathing room, and it can genuinely reduce the odds that your system of record dies because an air conditioner did. Those are real wins, and for a lot of shops they're reason enough.

The key is to buy it for what it is — an infrastructure change — and not for benefits it was never going to provide.

When it's just lipstick

Here's the part the pitch deck skips. Lift-and-shift moves your problems with perfect fidelity, because that's the definition of it. Whatever was making your ERP painful comes along for the ride.

The integrations that break monthly will break monthly in the cloud. The Crystal reports nobody can read will be equally unreadable at a higher latency. The DML and EMF customizations that only one person understood are now that person's problem and a line item on a recurring invoice. You have not fixed anything. You've re-hosted it and started renting it. That's the trap: it feels like progress because something big and scary happened, but the thing that happened wasn't the thing that was hurting you.

The honest sequence

So what should you actually do? Treat lift-and-shift as step zero, not the destination.

Move the box to get off the failing hardware and buy yourself a stable place to stand. Fine. Then do the modernization that was always the real work, on top of that stable base: wrap the ERP in an integration layer so the rest of your stack can reach it, fix the reporting and document delivery that generate the daily misery, put AI where the data is genuinely useful, and replace only the specific parts that actually hurt. (I've written the longer version of that sequence separately — it's the same layered approach whether your ERP lives in a closet or a cloud region.)

The cloud, in other words, is where the modernization happens. It is not the modernization. Confusing the location for the outcome is how a company spends a year and a budget to arrive at the same problems with a better ping time.

SaaS-friendly as a design goal

There's a better mindset than "get us to the cloud," and it's "make the next move easier than this one was." Every layer you add after the rehost — the API around the ERP, the modern reporting, the automated document delivery — should be built to be portable, observable, and maintainable by someone you can actually hire. Do that and each subsequent step gets cheaper, because you're no longer re-hosting the same trap at higher resolution. Skip it and you'll be having this exact conversation again in three years, with the same slides and a larger invoice.

The bottom line

Lift-and-shift isn't a scam and it isn't a solution — it's a moving service. It's the right call when the goal is to get off dying hardware and onto stable ground, and a disappointment when it's sold as modernization. Buy it for what it is, then do the actual work on top. The cloud will happily host your problems. It won't fix them for you, and it was never going to.

Been promised a lift-and-shift and left wondering what you actually got? Let's map the part that comes after the move →. Related: how to think about modernizing Ross ERP in 2026.