The management group and subscription hierarchy is the skeleton of your Azure governance. Every policy assignment, every RBAC assignment, and every cost boundary inherits from it. Get it right, and governance scales naturally. Get it wrong, and you face a choice between painful restructuring or permanent workarounds.
Management Group Design Principles
The hierarchy exists to allow governance to be applied at the right scope without duplication.
Depth versus breadth is the first structural decision. Deeper hierarchies allow finer-grained policy inheritance but increase complexity.
Practical design approach: This hierarchy becomes the foundation for policy assignment and RBAC scoping. See Azure RBAC Design for Large Organisations: Principles Over Permissions and Azure Policy for Cost Governance: The Three Rules That Matter Most to understand how your hierarchy decisions propagate downstream. The mixed model is where most enterprise organisations land: platform subscriptions (connectivity, identity, management) and application workloads separated by environment.
The “one subscription for everything” pattern is a common trap for organisations that started small. The structural problem is that blast radius and cost attribution collapse into a single unit. You cannot apply a stricter policy to production without it affecting dev. Restructuring out of this is essential, but it takes time and a solid migration plan.
The Decisions That Determine Everything Downstream
Root management group policies are your highest-leverage tool. Use this scope only for policies that genuinely apply universally: mandatory logging, prohibited resource types, and required diagnostic settings. Overusing the root scope is a common mistake that leads to a mile-long exemption list.
The Sandbox Strategy: A dedicated scope for experimentation is vital. It prevents engineers from testing in production-governed environments where they will inevitably hit a “Deny” policy and get frustrated.
Delegated Sandbox Ownership: I prefer a model where each business line or department has its own sandbox. This shifts the responsibility away from the central platform team. Each department can handle provisioning environments for their own developers, ensuring they have the freedom to experiment while staying within their specific budget. It keeps the platform team from becoming a bottleneck for every single “I just need a place to test this” request.
Restructuring an Existing Hierarchy
Moving subscriptions between management groups is supported, but it has immediate consequences. Inherited policies from the old parent are removed, and new ones from the target are applied instantly.
The brownfield reality is that most hierarchies grew rather than being designed. Restructuring is possible, but you must define your target state before you move a single subscription. Migrating without a destination produces a “Frankenstein” hierarchy where nobody is quite sure what policies are actually in effect.
Management group design is one of the few Azure decisions where the cost of getting it wrong compounds. Each new subscription added to a poor hierarchy increases the technical debt. The best time to get this right was yesterday; the second-best time is today, with a clear migration plan.
