Lift and Shift

The fastest and lowest-risk migration treatment, and the one most often criticised for the wrong reasons.

When it is right: a data-centre exit or lease expiry with a hard date; a large estate where per-application optimisation would take years; a system that will be retired within a few years and does not warrant investment; or as a first step that gets the workload onto a platform where later optimisation becomes possible.

What it does not do: improve anything. The application arrives with the same architecture, the same operational characteristics and the same constraints — and frequently a higher running cost, because infrastructure sized generously for owned hardware is billed by the hour in a cloud.

That cost surprise is the single most common outcome of a naive lift-and-shift programme, and it is predictable: rightsizing during or immediately after migration is what prevents it.

The honest framing for a business audience: lift and shift buys speed and a deadline, and defers the optimisation. It becomes a failure only when the deferred work is never funded — which is why a follow-on optimisation phase with its own budget should be part of the original approval rather than a later request.

The related trap: rehosting something that should have been retired. Migration effort spent on a system with fourteen users is the most avoidable cost in any programme.