When lift and shift is the right answer

What does lift and shift actually mean?

Moving a workload to cloud infrastructure with as few changes as possible: the same operating system, the same application, the same architecture, running on virtual machines instead of your own hardware. Nothing is containerised, nothing is decomposed, and the deployment process usually stays exactly as it was.

The value is speed and containment of risk. Because the application does not change, the testing burden is about the environment rather than about behaviour, which means a migration that would take eighteen months as a rearchitecture can take a few months as a move. That difference is the entire argument, and against a hard deadline it is decisive.

It is worth separating this from replatforming, which keeps the application but swaps its supporting pieces: your self-managed database for a managed one, your virtual machine for a container, your cron server for a scheduled job. Replatforming captures a meaningful share of the operational benefit for a small fraction of the work of a rewrite, and it is frequently the option that should have been chosen instead of either extreme.

When is it the right call?

Four situations, and they share a shape: the deadline or the risk is external, and rearchitecting does not change it. A datacentre lease or contract ending on a fixed date. Hardware or a support contract reaching end of life, where staying put means an unsupported system. An application scheduled for replacement within a couple of years, where investment in its architecture will be discarded. And a system nobody left in the organisation fully understands, where changing it and moving it at the same time makes any failure impossible to diagnose.

That last one is the most underrated. Moving an application unchanged means any problem after the move is an environment problem, which is a small and searchable space. Moving and rearchitecting simultaneously means every problem could be either, and the investigation cost of that ambiguity is routinely larger than the work saved by combining the two.

There is a fifth, quieter case: a workload that is simply fine. Steady load, low change rate, no scaling requirement, and nobody complaining. Rearchitecting it produces a technically superior system that delivers nothing to the business, and the engineering time has an alternative use.

What does each option actually cost you?

The trade is between the effort now, the running cost afterwards, and what you are able to do next. Lift and shift minimises the first, worsens the second, and leaves the third roughly where it was. A rebuild inverts all three. The middle options are where most workloads should end up and where fewest do, because they are less satisfying to argue for in a meeting.

Why do lifted workloads often cost more in the cloud?

Because you move a machine sized for peak and then pay for that size every hour, where the same over-provisioning in your own rack was a sunk capital cost that felt free. A server bought three years ago and running at fifteen per cent utilisation costs nothing extra at fifteen per cent. The same specification rented costs the full amount whether it is busy or idle.

Storage behaves similarly and less obviously. Local disks in owned hardware are effectively unmetered once bought, while cloud block storage is billed on provisioned capacity and often separately on provisioned throughput, so a database configured for a spinning-disk era with generous headroom can carry a substantial monthly charge for capacity it will never use.

The fix is right-sizing, and it needs actual utilisation data rather than the original specification. Measure for a full business cycle, including month end and any seasonal peak, then size to the observed peak plus headroom. This is the single highest-return activity after a lift and shift, and it usually recovers a meaningful part of the difference within the first quarter.

What should you change even in a pure lift?

Five things, none of which touch application code. Identity, so access is through the cloud identity provider with multi-factor authentication rather than the local accounts that came with the machines. Network segmentation, because a flat network that was acceptable behind a firewall in a building is a different proposition in a public cloud account. Backups, tested by restoring rather than by checking that the job ran. Monitoring, at least at the level of host health and disk capacity. And a repeatable build for the machine image, so the server can be recreated rather than restored.

The last one is the difference between a migration and a copy. If the only record of how that server was configured is the server itself, you have moved a single point of failure rather than removed one, and the first time it needs recreating under pressure you will discover which undocumented change from four years ago was load bearing.

None of these require rearchitecting and all of them are cheaper during the move than afterwards, because the machine is already being touched and the change window already exists.

How do you stop the temporary state becoming permanent?

By writing down what happens next while the migration is still funded, and by attaching it to a specific trigger rather than a date. Dates in a modernisation plan slip indefinitely because nothing forces them. Triggers do not: the next major version upgrade of the runtime, the next significant feature in that area, the next time the workload needs more capacity. Each is a moment when someone will be in the code anyway.

It also helps to be explicit that the lifted state is more expensive to run, and to make that visible on the same report as everything else. A cost line that nobody sees generates no pressure, and the argument for replatforming is usually easiest to win with a number rather than an architectural preference.

And accept that some workloads should stay lifted forever. If an application is stable, cheap enough, and nobody is asking anything new of it, leaving it on a virtual machine is a legitimate end state rather than technical debt. Modernisation is worth doing where it changes what the business can do, and treating it as a moral obligation is how engineering time gets spent on systems nobody was complaining about.