The Cloud Landing Zone Redesign Checklist: Fix What Blocks Teams, Not the Diagram

Almost every enterprise that has been on a hyperscaler for more than three years has a landing zone that no longer fits. It was built once, by a small platform team, against whatever reference architecture the vendor shipped that year. The business grew, the account count exploded, acquisitions arrived with their own tenants, and the original guardrails quietly stopped matching how teams actually work. The landing zone still runs. It also blocks people daily.

We get called in when the symptoms become impossible to ignore: a new business unit waits six weeks for its first production account, a security finding cannot be remediated because nobody owns the shared network, or a single overloaded transit hub becomes the reason a launch slips. The instinct at that point is to declare the old landing zone a mistake and rebuild it on the latest accelerator. That instinct is usually wrong, and it is the most expensive way to spend the next year.

What a landing zone actually is

A landing zone is the set of foundational decisions every workload inherits before a single application ship. Strip away the marketing and it is six things: the account or subscription topology, the identity and access model, the network topology, the policy guardrails, the logging and audit plane, and the infrastructure-as-code baseline that provisions all of it. Nothing else. If a decision does not belong to one of those six, it is not landing zone scope, and dragging it in is how redesigns balloon.

The vendors describe the target state well. Microsoft's Cloud Adoption Framework enterprise-scale landing zones and Amazon's AWS Control Tower and multi-account guidance both converge on the same shape: a management or organization root, a small number of platform accounts for shared services, and workload accounts fanned out under organizational units that map to teams and environments. That target is sound. The problem is never the target diagram. The problem is the distance between it and what you actually have, and the cost of closing that distance while production keeps running.

The contrarian framing: a landing zone is a product, not a project

Most redesign proposals we review are written as projects. They have a start date, an end date, a target architecture, and a migration plan that moves every account onto the new foundation in one program. That framing is the root cause of failure. A landing zone touched as a one-time project ages the moment the project closes, because the org keeps changing and the foundation does not.

The counter-take we offer is simple: treat the landing zone as a versioned product with an owning team, a backlog, and a deprecation policy for old patterns. You do not migrate everything. You publish a new version of a specific control, provide a paved path onto it, and retire the old pattern on a clock. A redesign under this model is not a big-bang cutover. It is a sequence of targeted structural fixes, each shipped independently, each reversible, applied to the parts that measurably block teams.

This matters because the big-bang rebuild has a dismal completion record. We have watched three separate enterprises start a full landing-zone re-platform, migrate 20 to 30 percent of accounts, hit an unmovable legacy estate, and then run two foundations in parallel for years. Running two landing zones is worse than running one bad one. The redesign that finishes is the one scoped to the specific seams that hurt.

Before you touch anything: the diagnosis checklist

A redesign that starts with a target diagram is already off track. Start with a diagnosis. Score the current landing zone against these questions, and let the failing answers define scope. Everything that passes stays untouched.

• Account and subscription topology. Does the boundary follow blast radius, ownership, and billing, or does it follow the vendor sample org chart? A workload account should be the unit of isolation for a team and an environment. If one account holds four teams' production workloads, a single misconfigured role can cross all four.
• Identity and access. Is human access federated through your identity provider with short-lived credentials, or are there long-lived access keys older than 90 days? Standing keys are the single most common finding we log, and they are the fastest to fix.
• Network topology. Is address space centrally allocated with a non-overlapping plan, or did teams pick their own ranges? Overlapping ranges are the defect that makes every later merger and every private connection painful. A /16 per region per environment, carved into /24 subnets, buys years of headroom for most estates.
• Policy guardrails. Are controls preventive (a policy that denies the action) or detective (an alert after the fact)? Detective-only guardrails mean your foundation documents violations rather than stopping them.
• Logging and audit plane. Do audit logs land in a dedicated account that workload teams cannot alter, with a retention period your regulator accepts? If the team that can cause an incident can also edit the logs, you have no audit plane.
• Provisioning baseline. Can a new compliant account be stood up from code in under one day, or does it take a ticket queue and manual steps? The provisioning time is the truest measure of landing-zone health.

Write down a number for each. The ones that fail become the redesign backlog, ranked by how many teams they block.

The redesign sequence that actually finishes

Order matters more than completeness. These fixes have dependencies, and doing them out of sequence forces rework.

1. Stand up the audit and logging plane first, in its own account. Every later change is safer when you can see its effect. Centralize audit logs, enable them across all existing accounts, and lock write access away from workload teams. This is non-negotiable groundwork and typically takes 1 to 2 weeks.
2. Fix identity before topology. Federate human access, kill long-lived keys, and move to role assumption with short-lived credentials. NIST's zero trust architecture guidance, SP 800-207, frames the principle we apply here: never grant standing access you can grant on demand. Identity fixes are account-independent, so you can ship them before any topology change.
3. Convert critical guardrails from detective to preventive. Take the five or six controls that map to your worst audit findings and express them as deny policies at the organization or management-group level. Preventive controls at the root protect every account, including the ones you have not migrated yet.
4. Re-lay network address space only where it overlaps or has run out. This is the most invasive step, so it comes late and only where the diagnosis flagged it. Allocate a clean plan, route new accounts into it, and migrate overlapping estates one workload at a time behind a documented cutover.
5. Rework account topology last, and only by moving new work. Do not mass-migrate existing accounts across organizational units. Publish the new structure, route every new account into it, and let attrition thin the old layout. Most estates never need to move the legacy accounts at all.
6. Codify the whole baseline so version two is provisioned, not clicked. The output of the redesign is a paved path: a pipeline that stamps out a compliant account with logging, identity, guardrails, and networking wired in, in under one day.

Notice that four of the six steps require no account migration at all. That is the point. The redesign that finishes touches the control plane far more than it touches workloads.

What does not belong in a landing zone redesign

Scope discipline is what separates a 12-week redesign from an 18-month one. We keep three things out on purpose.

Workload re-architecture does not belong here. The landing zone provides the foundation; it does not refactor the applications sitting on it. When a redesign starts pulling in "and while we are at it, let us containerize the monolith," accountability dissolves and the timeline detaches from reality.

Cost optimization does not belong here either, even though a cleaner topology makes cost allocation easier. Bundling a cost program into a foundation program dilutes both, and the executive attention that funds the redesign wanders when the metrics blur. Ship the foundation, then run cost work against the cleaner tagging it produces.

Full multi-cloud abstraction does not belong here. A landing zone is per-provider. Building a cloud-agnostic control plane on top of a redesign is a different, far larger program, and folding it in guarantees neither finishes.

Measuring whether the redesign worked

A foundation program with no metric is theater. We hold every landing-zone redesign to four numbers, measured before and after.

Time to a compliant production account, from request to usable, is the headline. A healthy landing zone delivers this in under one day; the estates we are called into often sit at 4 to 6 weeks. Second, the count of preventive controls versus detective ones, because a foundation that only detects is not a foundation. Third, the number of long-lived credentials older than 90 days, which should trend to zero. Fourth, the share of accounts provisioned from the codified pipeline rather than by hand, which tells you whether version two is actually spreading or just documented.

The CIS Benchmarks give a defensible external baseline for several of these controls, and mapping your preventive guardrails to a published benchmark makes the security posture auditable rather than a matter of internal opinion. When those four numbers move in the right direction, the redesign paid for itself. When they do not, you rebuilt a diagram.

Where to start

The failure mode is analysis: a beautiful target architecture that never ships because the migration is too big. Avoid it by starting narrow and shipping this quarter.

1. Run the six-part diagnosis this week and write a number next to each line. The failing lines are your entire scope; everything else is out.
2. Stand up the audit and logging plane in a dedicated account before any other change, so every later fix is observable.
3. Fix identity next, because it is account-independent and removes your most common finding without touching topology.
4. Convert your five worst audit findings into preventive deny policies at the root, protecting migrated and unmigrated accounts alike.
5. Name an owning team and a version number for the landing zone, and give it a backlog and a deprecation policy, so version three does not require another rescue in three years.