The modernisation trap: why lift-and-shift stalls at 60%

The first wave of any cloud migration is genuinely easy. Stateless web tiers, internal tools, anything already containerised - these move in weeks and produce an encouraging progress chart. Steering committees see momentum and approve the next tranche of budget.

What remains is the hard core: the batch job nobody can explain, the licensing arrangement tied to a physical host, the reporting database eleven other systems read from directly, and the integration written by someone who left in 2016. None of these appear on the original inventory because inventories are built from asset registers, not from traffic.

The programme then enters the worst possible state - running two estates in parallel. You pay for the data centre and the cloud, you operate two networks, and your engineers context-switch between both. Costs peak precisely when confidence is lowest, which is when migrations get quietly paused.

The fix is unglamorous: establish the real dependency graph before committing to a wave plan. Not from documentation - from observation. Network flow logs, database connection audits and query logs over a full business cycle, including month-end and year-end, tell you what actually talks to what.

Then sequence around the parallel-running window rather than around individual application difficulty. The goal of wave one is not to move the most applications; it is to reach the earliest point at which an entire dependency cluster can be cut over and the corresponding on-premise capacity switched off. A cluster half-migrated saves nothing.

This usually means tackling something uncomfortable early. If the reporting database is the hub everything routes through, it belongs in the first wave - behind an interface that lets consumers migrate independently afterwards. It is more work up front and it is the difference between finishing and stalling.

Lift-and-shift is not a mistake in itself; treating it as the finish line is. A workload rehosted unchanged carries its on-premise sizing assumptions with it - provisioned for peak, running constantly, with no autoscaling and no managed-service substitution. That is why the bill rises.

Score each workload on run cost, change frequency and business criticality. Frequently changed, expensive workloads justify re-architecting. Stable, cheap ones can sit rehosted indefinitely without shame. The mistake is applying one strategy uniformly because it is easier to explain in a steering pack.