Cloud Migration

Definition

Migration strategies, from least to most change: rehost (lift and shift), replatform (minor optimisation), refactor (redesign for cloud-native), repurchase (replace with SaaS), retire, and retain (leave it where it is).

The decision is per workload, not per programme. A portfolio typically retires 10–20% of applications on inspection, which is the cheapest win available and is routinely skipped because nobody wants to own the conversation.

Why lift-and-shift produces a bad bill

Moving a VM sized for a peak from 2019 into the cloud at the same size means paying hourly for capacity that was already bought. On-premises, over-provisioning is a sunk cost; in the cloud it is a recurring one. Add cross-AZ traffic charges for a chatty application never designed to care, plus egress for data flows that were previously free, and the bill routinely exceeds the data-centre cost it replaced.

That outcome then discredits the migration politically, even when the strategic reasons for it were sound.

The fix is not to refactor everything — that is slow and expensive. It is to replatform selectively: right-size against actual utilisation, move storage to appropriate tiers, adopt managed services for the components that dominate operational time, and address the two or three data flows that generate transfer charges.

Industry example

The most useful counter-case is Dropbox's move of storage out of a public cloud, which was economically correct at their scale and for that specific workload. It is frequently cited as evidence that cloud economics are bad in general, and it is not that: it is evidence that at very large scale, for a uniform workload that dominates your cost base, owning infrastructure can win.

The transferable practice is the one both directions share — calculate rather than assume. The same discipline that justified their move out is the discipline that justifies most organisations' move in, and the answer differs by workload and scale rather than by philosophy.

The sequence that works

1. Inventory and rationalise. Retire, and identify what to repurchase as SaaS.
2. Establish the landing zone first — identity, network, guardrails, logging, cost allocation. Migrating into an ungoverned account creates a mess that must be unpicked later.
3. Start with something low-risk and real, to learn the pipeline end to end.
4. Move data-adjacent workloads together. Splitting a chatty application from its database across the boundary produces latency and transfer charges that can kill a migration.
5. Right-size after a period of real measurement, not at the point of the move.
6. Decommission the source. Budget it explicitly, or you pay for both indefinitely.

Failure scenarios

• No landing zone, so governance is retrofitted across hundreds of resources.
• Application and database split across the boundary during a phased move.
• No cost allocation tags from day one, making it impossible to attribute spend later.
• The old environment never decommissioned.

Interview question

"A lift-and-shift migration has produced a cloud bill 2.5x the data-centre cost. What do you look at first, and what is the fastest meaningful reduction?"