Azure Landing Zones: The Governance Work Nobody Budgets For

Almost every Azure environment we're brought in to untangle started the same way: a single subscription, a handful of resource groups, and no management group hierarchy — because the initial workload didn't seem to need one. Eighteen months and thirty teams later, that early shortcut is the reason nobody can answer "who owns this resource" or "what policy applies here" with confidence.

A Landing Zone Isn't Infrastructure — It's Governance

Microsoft's Cloud Adoption Framework landing zone reference architecture gets treated as an enterprise-scale concern that mid-market companies can skip. That's backwards. The landing zone pattern — a management group hierarchy, policy-as-code enforcement, and a subscription vending process — is exactly the structure that keeps a growing Azure footprint manageable by a small team. Without it, governance doesn't disappear; it just becomes manual, inconsistent, and eventually unenforceable.

What Gets Skipped, and What It Costs Later

• No management group hierarchy — policies get applied subscription by subscription, inconsistently, instead of inherited from a structure that maps to your org.
• No policy-as-code baseline — tagging, allowed regions, and encryption requirements exist as a wiki page instead of an enforced Azure Policy assignment, so compliance depends on someone remembering to check.
• No subscription vending process — every new team's subscription gets provisioned by hand, with whatever settings the person doing it remembers that week, guaranteeing drift.
• No clear platform vs. application landing zone separation — shared services (networking, identity, logging) end up entangled with individual application resources, making it impossible to change one without risking the other.

The cost of skipping a landing zone doesn't show up in month one. It shows up as the migration project that has to happen anyway, eighteen months later, except now with production workloads live and zero downtime tolerance.

What We Recommend at the Start of an Azure Engagement

Stand up the management group hierarchy and a minimal policy-as-code baseline before the first production workload lands — not after the third team asks for a subscription. Use Azure's landing zone Bicep or Terraform modules rather than building the structure by hand; the maintenance burden of a hand-rolled version compounds fast. Define the subscription vending process on day one, even if it's simple, so it exists before anyone needs to work around its absence.