intermediate 2 min answer

When is lift-and-shift the right migration strategy, and what must be planned alongside it?

rehostmigrationcostreplatformdeadline
Show the full answer Hide the answer

What is being tested

Whether you can defend a strategy that produces a bad bill, by planning the phase that fixes it.

When it is right

  • A data centre exit with a deadline. Nothing else is fast enough when a lease expires.
  • Applications due for retirement or replacement within a couple of years, where modernisation investment would be wasted.
  • Vendor software you cannot modify.
  • As a deliberate first step, with replatforming funded and scheduled afterwards. Getting out of the data centre is a legitimate goal on its own.

What must be planned alongside

A funded replatforming phase, immediately after. Without it the temporary bill becomes permanent and the migration is discredited politically even where the strategic reasoning was sound.

The reason the bill is bad: on-premises, over-provisioning is a sunk cost; in the cloud it is recurring. A VM sized for a 2019 peak now costs money hourly, forever, for capacity already paid for once. Add transfer charges for flows that were previously free — cross-zone chatter on every request — and storage provisioned at peak in premium tiers.

The remediation, in order of return:

  1. Right-size against two weeks of real utilisation — typically 30–50%.
  2. Schedule non-production shutdown — often 60–70% of non-production spend.
  3. Private endpoints so service traffic bypasses NAT per-gigabyte processing charges.
  4. Commitments, after right-sizing.
  5. Managed services for the components dominating operational time.

Steps one and two are configuration changes and routinely halve the bill within weeks.

The other things to plan

Inventory and rationalise first. Ten to twenty per cent of a portfolio typically retires on inspection — the cheapest win available, and skipped because nobody wants to own the conversation.

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.

Cost allocation tags from day one, or later attribution is impossible and every optimisation conversation stalls on ownership.

Budget the decommissioning of the source, or both are paid for indefinitely.