There is a familiar shape to cloud migrations that disappoint. Someone runs a pilot, it works, confidence rises, and workloads start moving. Eighteen months later the bill is larger than the data centre it replaced, access is granted by ticket because there is no role model, and nobody can say which of the forty accounts owns which workload.

Almost none of that is caused by the migration itself. It is caused by migrating into a space that had no structure waiting for it.

What a landing zone actually is

A landing zone is the answer to a set of questions you will otherwise answer forty separate times, inconsistently:

  • Account structure. What separates production from non-production, and which team owns which boundary?
  • Network topology. How do workloads reach each other, the internet and whatever remains on-premise?
  • Identity. Who can do what, in which environment, and how is that granted and revoked?
  • Logging and audit. Where do logs go, who can read them, and how long are they kept?
  • Cost allocation. Which tags are mandatory, and how does spend get attributed to a team?
  • Guardrails. Which actions are denied outright by policy, rather than by convention?

Every one of these is significantly cheaper to decide once, before workloads arrive, than to retrofit across a live estate.

Retrofitting a tagging strategy onto 200 running resources is not a technical problem. It is forty conversations with people who have other priorities.

The cost question is really an attribution question

When a cloud bill is described as out of control, the underlying problem is usually not the total. It is that no team feels responsible for any part of it. Without mandatory tags enforced at creation, spend belongs to the company in aggregate and to nobody in particular.

Enforcing tags from the first day is close to free. Adding them later means finding an owner for every untagged resource, and the ones nobody claims are exactly the ones nobody dares delete.

What we do instead

We build the landing zone as code, review it against the organisation's actual compliance obligations, then migrate two or three genuinely low-risk workloads end to end. That pilot wave exists to test the runbook, not to prove the cloud works.

Only then do the real waves start, sequenced by dependency, each with a tested rollback. It feels slower for about six weeks. It is faster by month four, and the difference compounds from there.

The honest trade-off

This approach front-loads work that produces nothing visible to the business. There is a stretch where the answer to “what have we migrated?” is “nothing yet, but we can now migrate safely.” That is a genuinely uncomfortable conversation.

It is a much better conversation than the one about why the bill tripled.