practice

Rehost

also called Lift and Shift

Moving a workload to new infrastructure with no change to the application — fastest, cheapest to execute, and the source of the bill that discredits migrations.

migrationrehostcloudcostspeed

Definition

Rehosting moves a workload as-is: the same operating system, the same application, the same configuration, running on a new platform. No code changes.

When it is the right choice

  • A data centre exit with a deadline. Rehosting is the only strategy fast enough when a lease expires.
  • Applications that will be retired or replaced within a couple of years. Investing in modernisation would be wasted.
  • Vendor software you cannot modify.
  • As a first step, deliberately, with replatforming planned afterwards. Getting out of the data centre is a legitimate goal on its own.

Why the bill surprises people

On-premises, over-provisioning is a sunk cost — the hardware is bought and idle capacity is free. In the cloud it is recurring. Moving a VM sized for a 2019 peak means paying hourly, forever, for capacity that was already paid for once.

Compounded by data transfer charges for flows that were previously free — cross-availability-zone traffic on every request from a chatty application that never had to care — and by storage provisioned at peak in premium tiers by default.

A bill 2 to 3 times the data-centre cost is common, and it discredits the migration politically even when the strategic reasoning was sound.

The mitigation, planned in advance

Commit to a replatforming phase, funded, immediately after the move: right-size against two weeks of real utilisation, schedule non-production shutdown, add private endpoints so service traffic bypasses NAT charges, and adopt managed services for the components dominating operational time.

Right-sizing plus non-production scheduling alone routinely halves the bill within weeks, and both are configuration changes.

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.

Failure scenarios

  • No replatforming phase, so the temporary bill becomes permanent.
  • Application and database split during a phased move.
  • No cost allocation tags from day one, making later attribution impossible.
  • The source environment never decommissioned, so both are paid for indefinitely.
  • Rehosting something that should have been retired. Inventory first — 10–20% of a portfolio typically retires on inspection.

Interview question

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