A little while ago I wrote some field notes from moving an on-premises warehouse to Azure, and I ended them with a promise: that the interesting argument wasn't in the moving, it was in what you do after you land. This is me keeping that promise. Because I've now watched the pattern up close, and I've become slightly evangelical about a single sentence I'll repeat until people are sick of it: lift-and-shift is not a strategy. It's a postponement.

Let me make the case properly, because it's easy to nod at and hard to actually live by when a deadline is bearing down.

The seductive logic of moving without changing

The appeal of lift-and-shift is obvious, and I want to state it fairly before I argue with it, because it's genuinely reasonable.

You have a working system. Rewriting it is slow and risky. The cloud provider is, in effect, offering to host essentially the same thing in their data centre. So you take the on-prem warehouse — the databases, the nightly batch jobs, the stored procedures nobody fully understands any more — and you relocate it, more or less intact, onto infrastructure in the cloud. The project plan is clean. The migration "succeeds." Everyone gets to stand up in the steering committee and say the cloud programme delivered on time.

And as a first move, this is even defensible. Getting the system running in the new place before you start changing how it works is a legitimate way to de-risk. I'm not against lift-and-shift as a step.

I'm against it as a destination. Because then the invoices start arriving.

Why the invoices are the whole argument

Here's the thing that makes lift-and-shift quietly expensive, and it's worth understanding at the level of why, not just as a warning.

An on-premises architecture was shaped, in every joint, by on-premises constraints — most of which silently stop being true the moment you move.

  • You'd already bought the hardware, so its capacity was a sunk cost. That meant a wasteful overnight batch cost you nothing extra — the machine was sitting there anyway. So on-prem designs are full of "just reprocess everything every night," because profligacy was free.
  • Storage and compute lived on the same physical box, welded together, because that's how a server is built. So on-prem designs assume you scale them as one lump, because you had no choice.
  • Work happened in overnight windows because that's when the shared, finite machine was free.

Now move that design, unchanged, to a place where you pay by the hour for compute, pay separately for storage, and can scale each independently and instantly. Every one of those inherited assumptions inverts from "sensible" to "expensive." The wasteful batch that was free now runs a meter. The welded storage-and-compute means you over-provision one to get enough of the other, and pay for the waste continuously. You didn't migrate a system. You migrated a set of decisions that no longer make any sense in the place you've moved them to — and then you pay rent on that mismatch, every hour, forever.

That's why lift-and-shift so often ends with a version of "the cloud turned out more expensive than we were promised." The cloud didn't lie. The architecture did — by pretending its old constraints still applied.

What the cloud actually asks of you

The migrations that pay off treat the move as a forcing function to rethink, not just relocate. Concretely, that means confronting a few things the old world let you ignore:

  • Decouple storage and compute. The entire economic model of cloud data platforms rests on this separation — scaling compute up for a heavy job and back down after, without touching your storage. A design that assumes the two are joined, because on a physical server they were, has to be genuinely reworked, not merely re-hosted, to capture any of the benefit.
  • Move from batch-by-default to demand-driven thinking. The nightly batch existed because of a constraint that's now gone. Clinging to it in the cloud means paying premium rates to faithfully preserve a limitation you no longer have.
  • Make cost a design constraint, not an afterthought. On-prem, the cost was sunk before the first query ran, so efficiency was optional. In the cloud, every inefficient join and every idle over-provisioned resource is a recurring charge. Architecture and finance stop being separate conversations. Waste becomes visible and continuous instead of hidden and one-time — which is uncomfortable, but it's the discipline that makes cloud pay off.

None of these are "move the database" tasks. They're "reconsider the design in light of what's now possible" tasks. And that reconsideration is the actual work — the part lift-and-shift is specifically designed to let you skip.

The deeper pattern, which isn't about the cloud at all

Here's why I care about this beyond one migration, and why I'll keep repeating that sentence.

Lift-and-shift is a pattern of thinking, and it shows up at every technology transition, not just this one. The pattern is: when a genuinely new capability arrives, the tempting first move is to use it to do the old thing slightly cheaper or faster, without changing the old thing. It feels prudent. It de-risks the project. And it forfeits almost all of the actual value — because the value was never in doing the same thing in a new place. It was in the new things the capability makes possible that weren't possible before.

Cloud didn't just offer a cheaper data centre. It offered elasticity, separation of storage and compute, services that didn't exist on your own hardware — a different set of possible designs. Lift-and-shift takes delivery of all that and then carefully uses none of it, like buying a workshop full of power tools and continuing to saw everything by hand because that's how you've always done it.

The question that separates a strategy from a postponement isn't "how do we move this?" It's "given what's now possible, what should this become?"

I've started to think you can predict which cloud programmes will disappoint just from which question they asked at the start. The ones that asked "how do we move it?" get across the water and wonder why the invoice went up and nothing got better. The ones that asked "what should this be now?" occasionally struggle more at first — rethinking is harder than relocating — but they come out the other side able to do things they genuinely couldn't do before.

Where this leaves me

I'm still early in my data-engineering career, and I'm wary of sounding like I've got it all worked out. But this is one thing I've seen clearly enough, up close and expensively enough, to plant a flag on.

Lift-and-shift is a fine way to cross the water safely. It is a terrible place to stop. If the migration is the whole plan, you've signed up for the disruption of moving and the cost of the cloud without the benefit that was supposed to justify either. The benefit lives entirely in the part everyone's tempted to skip — the re-architecting that comes after you land, when you finally ask what the system should be now that the old rules don't apply.

So: move safely if you must. But don't call the move a strategy. The strategy starts the morning after, with a harder and much more valuable question than "did it migrate?" — namely, "now that we're here, what should we actually build?"