The framing problem

Most cloud migrations are framed as a move. Something is in one place; it needs to be in another place; the project is complete when the move is finished. That framing is what produces the two most common outcomes: a data centre reproduced in a hyperscaler at higher cost, or a programme that overruns because a third of the estate turned out to need redesigning.

The better framing is that a migration is a portfolio decision exercise with an implementation attached. The decisions are made once, per workload, against a consistent framework. The implementation is then largely repetitive.

The seven dispositions

1. Retire

Switch it off. This is the highest-value disposition available and the one most consistently skipped, because retirement requires someone to take responsibility for a decision while rehosting requires nobody to.

Candidates: applications with no active users in ninety days, reporting systems superseded by a newer tool but never turned off, environments provisioned for a project that ended, duplicate systems inherited through acquisition. On a typical enterprise estate, retirement candidates run between 15% and 25% of workloads. On one recent engagement it was 61 out of 280.

The blocker is never technical. It is that nobody wants to be the person who switched off a system that turned out to matter. Solve it with process: a written notice period, a shutdown-but-do-not-delete window of thirty days, and a documented restore path.

2. Retain

Leave it where it is, for now, deliberately and with a review date. Legitimate reasons include hardware dependency, a licence that does not permit cloud deployment, a regulatory constraint on data location, an application at end of life with a replacement already in flight, or latency coupling to a physical process.

Retain is a decision, not a deferral. Write down the reason and the date it will be revisited. Without that, retained workloads become the permanent residue that keeps the data centre contract alive.

3. Rehost

Move the virtual machine as it is. Fast, low risk, and the correct answer for a large share of a typical estate. Its reputation suffers because organisations rehost everything and are then surprised that the run cost is higher than the depreciated on-premises hardware.

Rehosting is economical when paired with rightsizing. An estate provisioned for peak load in 2019 is typically running at 15–25% average utilisation. Rehosting at the observed size rather than the provisioned size is where a meaningful share of the business case actually comes from.

4. Relocate

Move a whole virtualisation estate to a cloud-hosted equivalent of the same hypervisor. Minimal change, very fast, and useful when a data centre exit date is closer than the time needed to do the work properly. It buys time. It does not deliver cloud benefits, and it should be paired with a follow-up disposition plan for each workload.

5. Repurchase

Replace with SaaS. Frequently the right answer for anything non-differentiating — HR systems, service desks, expense management, CRM, collaboration. The migration effort becomes a data migration and an integration exercise rather than an infrastructure one, and the run cost moves from capital to operating expenditure.

The trap is integration debt. A repurchased system that needs eleven bespoke integrations to function is not obviously cheaper than the thing it replaced. Cost the integrations before, not after.

6. Replatform

Move with targeted changes that unlock managed services without redesigning the application: a self-managed database becomes a managed one, a file share becomes object storage, a VM-based queue becomes a managed queue.

This is usually the best return on effort in the whole framework. The operational burden drops substantially, the application code changes little, and the risk is contained. If a workload is going to receive engineering attention at all, replatform is the disposition to consider first.

7. Refactor

Redesign for cloud-native architecture. Genuine benefits — elasticity, resilience, deployment velocity — and genuine cost, both in engineering time and in risk.

The rule we apply: refactor no more than 10% of the estate during the migration itself, and only where a specific, named business constraint requires it. Everything else is refactored afterwards, from a stable cloud baseline, as normal product work. Migrations that refactor broadly are the ones that overrun, because refactoring is open-ended and migration deadlines are not.

Running the assessment

Every workload gets scored on five axes before a disposition is assigned:

  • Business criticality — what breaks, and for whom, if this is down for four hours?
  • Technical complexity — dependencies, custom integrations, undocumented configuration.
  • Change appetite — is there an owning team who can absorb change, or is it orphaned?
  • Compliance constraint — data classification, residency, audit scope.
  • Remaining life — is a replacement already planned?

Two people score independently and reconcile. This sounds like bureaucracy; in practice it is the mechanism that stops the loudest application owner from getting a refactor budget while a genuinely critical system gets a lift-and-shift.

Build the landing zone first

The landing zone is the account structure, network topology, identity federation, logging, and policy guardrails that every migrated workload lands into. Building it before wave one is non-negotiable, because retrofitting an account structure across two hundred live workloads is a second migration.

A landing zone we would hand over includes, at minimum:

  • Multi-account or multi-subscription separation by environment and by blast radius.
  • Network design with explicit egress control and private connectivity to what remains on premises.
  • Identity federation to the corporate directory; no long-lived local credentials.
  • Centralised logging and a retention policy that satisfies the strictest applicable framework.
  • Policy as code — guardrails that prevent public storage, unencrypted volumes and untagged resources at creation time.
  • A tagging standard that finance has reviewed and agreed to use for chargeback.

Wave planning

Group workloads into waves by dependency cluster, not by disposition or by team. Anything that shares a database, a file share, or a synchronous integration moves together, or you inherit a period of cross-premises latency that will be blamed on the cloud.

Sequence the waves so the first is low-criticality but non-trivial. A wave of five static websites proves nothing. A wave containing a real application with a database and two integrations proves the runbook, the cutover process and the rollback — while the consequences of getting it wrong are survivable.

Regulated and highest-criticality workloads go last, after the pattern has been executed successfully at least twice.

FinOps from day one

Cloud cost is a governance outcome, not an engineering accident. Three things need to exist before the first workload lands:

  1. A tagging standard, enforced at creation, mapping every resource to a cost centre and an owner.
  2. Showback reporting, so each business unit sees its own consumption monthly from the beginning rather than after the first alarming invoice.
  3. An anomaly alert on daily spend, at account level, with a named recipient.

Commitment purchasing — reserved instances, savings plans — should wait until you have three months of steady-state data. Buying commitments against a pre-migration forecast is how organisations end up committed to instance families they no longer run.

What goes wrong, ranked by frequency

  1. No retirement analysis. The whole estate is migrated because deciding is harder than moving. The business case never closes.
  2. Landing zone built in parallel with wave one. Early workloads land in a structure that is then revised, and get migrated twice.
  3. Unbounded refactoring. Refactor scope grows because it is genuinely valuable work, and the deadline does not move.
  4. Dependencies discovered at cutover. An undocumented integration surfaces during the outage window, when there is no time to design around it.
  5. No FinOps until the third invoice. By which point untagged spend is unattributable and nobody can be asked to reduce it.

Closing thought

The organisations that get the most from cloud migration are rarely the ones that refactored the most. They are the ones that were honest in the assessment: that switched off what was dead, rightsized what was oversized, replatformed where the operational burden was heaviest, and left the genuinely complex redesign work for a stable platform and a proper product backlog.