The work you do before the first workload moves determines whether the rest of the migration is uneventful.
The instinct on a migration is to demonstrate progress by moving something. Doing that before the account structure, network design and guardrails exist means retrofitting them later across live workloads, which is far harder.
Landing zone work feels like delay and is the reason the rest of the programme is boring.
Separate environments and separate teams into their own accounts or subscriptions. This gives clean blast-radius boundaries, straightforward cost attribution and simpler permission models.
A single account containing production and development is the arrangement most likely to produce an incident that could not otherwise have happened.
Guardrails enforced by policy hold. Guardrails documented in a standards page do not.
Federate to your existing identity provider rather than creating local users. Use short-lived credentials, require multi-factor authentication for anything privileged, and grant access through roles rather than to individuals.
Long-lived access keys in a repository remain one of the most common causes of cloud compromise, and they are entirely preventable at this stage.
A landing zone is not a one-off deliverable. Provider services change, new account types are needed, and policies require adjustment as the estate grows.
Treat it as a product with a maintainer: version the configuration, review the guardrails periodically, and have a defined route for teams to request an exception rather than working around a policy quietly.
Exception requests are valuable signal. A guardrail that generates constant exceptions is either wrong or badly explained, and either way it should be revisited rather than endured.
For a straightforward estate, a matter of weeks. Provider frameworks accelerate much of it. The variable is usually how long identity and network decisions take to agree internally.
Yes, but it is considerably more work. Moving live workloads between accounts, changing network layout and introducing tagging retrospectively all carry risk that greenfield setup does not.
A simplified version, yes. Even two or three accounts with enforced tagging, federated identity and centralised logging prevents most of the problems that make estates expensive later.
Keep reading
The overspend is rarely caused by the cloud itself. It is usually set in motion by three decisions taken in the first few weeks, often by people who did not realise they were making them.
All four run the same workloads competently. The decision usually follows existing commitments, data residency and the skills already in your team.
A meaningful share of cloud spend on a typical estate is recoverable without changing the architecture at all. Start there.
