The Lift-and-Shift Trap

Moving a workload to the cloud without redesigning it gives you cloud pricing on on-premises architecture. That is rarely a good deal.

Why the Worst Outcome Looks Like Progress

Lift-and-shift — taking a workload and rehosting it on cloud virtual machines without changing its design — is seductive precisely because it looks achievable. No refactoring, no re-architecture, no arguments about which managed services to adopt. You reproduce what you have, declare migration complete, and move on. The problem is that the workload you reproduced was built for a world the cloud doesn't resemble.

On-premises infrastructure is typically provisioned for peak load and then left running. That made sense when hardware was a capital purchase: once you owned the servers, idle time cost nothing incremental. Cloud infrastructure bills by the second. The moment you lift a workload designed around always-on, peak-provisioned servers into that environment, you inherit the worst property of each model — the operating expense of cloud without the elasticity that justifies it. What was once sunk cost becomes a recurring charge, and the idle tax that was invisible on-premises shows up on your invoice every month.

What Actually Goes Wrong

The failure is rarely dramatic. It accumulates in three predictable places.

Sizing carries over. On-premises engineers provision conservatively, because over-provisioning is safe and right-sizing is hard to revisit. Those habits migrate with the workload. A VM that was appropriately large for a physical server you couldn't resize becomes a persistently over-provisioned cloud instance that you're paying for continuously. Cloud tooling can surface this, but it rarely changes decisions already baked into Terraform files or AMI templates copied from the source environment.

Architecture assumes cheap internal traffic. Applications designed for a datacenter assume that east-west communication between components is essentially free. In the cloud, calls that cross availability zones, or that flow through a NAT gateway, attract charges. A chatty microservice design — or even a traditional three-tier application with a verbose ORM — can generate egress costs that were simply invisible on-premises. Nobody budgeted for them because there was nothing to budget.

Licensing follows the shape of the old world. Software licensed per physical socket or per server doesn't translate cleanly to per-vCPU or per-core cloud billing. Some vendors adjust; many don't in ways that benefit you. A database licensed for a four-socket server may require a renegotiation, an additional purchase, or a migration to a different edition before it runs legally at the scale you need. This is discovered after the migration, not before.

Why It Keeps Happening

Lift-and-shift persists because the people who decide to migrate are rarely the people who pay the bill six months later. Migration is a project with a deadline; optimisation is operational work with no natural endpoint. The incentive is to get something into the cloud, not to get something right in the cloud.

Lift-and-shift persists because the people who decide to migrate are rarely the people who pay the bill six months later.

There is also a genuine case for it in narrow circumstances: a workload heading for retirement, a datacenter lease that expires before a redesign is possible, a system so legacy that cloud-native services wouldn't accept it anyway. In those situations, lift-and-shift is a pragmatic holding pattern, and you should know you're making that choice consciously and price the ongoing inefficiency into your planning.

The trap springs when lift-and-shift is treated as a migration strategy rather than a migration tactic. When an organisation moves a hundred workloads this way and calls the cloud journey complete, it has built a cloud estate priced like a utility but engineered like a 2010 datacenter. The bill will reflect that indefinitely.

The corrective is not always full re-architecture — that has its own costs and risks. But it does require a deliberate answer to a question that lift-and-shift skips entirely: what, specifically, does this workload gain from being in the cloud? If the answer is nothing yet, that's an acceptable interim position. If the answer is nothing ever, the cloud may simply be the wrong place for it.