An organisation is starting cloud adoption. Three teams want to deploy next month. What must exist first, and what can wait?

What must exist before anything reaches production

Account structure. Separation by environment and by workload, because an account is the strongest isolation boundary a provider offers — for blast radius, quota, cost attribution and security. Retrofitting account separation later means migrating running workloads, which is expensive and rarely happens.

Non-overlapping address planning. The single most expensive thing to get wrong. Ranges must not collide with each other, with the corporate network, or with anything you may later peer with including an acquisition. CIDR ranges cannot be resized.

Identity federation and baseline roles. No local users, no shared credentials, no long-lived access keys. Establishing this after teams have created their own is a migration.

Centralised, immutable logging into an account nobody can delete from. Logs not captured from day one do not exist retrospectively, and that is exactly the period you will want to examine later.

A small set of preventive guardrails — region restriction, deny deletion of audit configuration, require encryption. Applied as service control policies so they cannot be overridden by an account owner.

Cost allocation tagging enforced at provisioning, because retrofitting tags to a running estate never reaches useful coverage.

What can wait

A full service catalogue. A complete policy library. A polished internal developer platform. Advanced network topology beyond what the first workloads need. Multi-region anything. A comprehensive reference architecture set.

These are valuable and they are all additive — they can be introduced against a correct foundation. The items in the first list are structural and become migrations if deferred.

How to satisfy the deadline

Give the three teams vended accounts from a minimal but correct foundation, and iterate the guardrails around them. A landing zone is a product with versions, not a project with a completion date — the important thing is that version one is structurally right, not that it is complete.

And build the migration path for existing accounts at the same time, or within a year the estate splits into "created before the standard" and "after", and the first group is never brought forward.

What a strong answer adds

Noting the trap in the other direction: landing zone programmes that spend six months perfecting governance while teams, blocked and impatient, create their own accounts on a corporate card. That produces exactly the ungoverned estate the programme existed to prevent. Ship version one in weeks, and accept that it will be revised.