Management Group Mistakes You Can't Easily Undo

The management group hierarchy is the load-bearing wall of an Azure landing zone. You design it once, usually in a hurry, with incomplete information and then you live with it for years. Subscriptions move, RBAC re-evaluates, policy assignments rebind, IaC references break, and the audit trail of who had access to what, when, gets muddy fast. Most teams treat the hierarchy as a day-one decision and never revisit it, which is exactly why the early mistakes calcify.

This is not a "best practices" post. These are the mistakes I've watched teams make including teams I've been on that turned into multi-quarter remediation efforts. If you're standing up a new landing zone, or you inherited one that feels off, read this before you touch anything.

Why MG changes are so sticky

Before the mistakes, it helps to understand why the hierarchy resists refactoring in the first place.

Management group IDs are immutable. The display name you see in the portal is not the same thing as the resource ID that your policy assignments and IaC reference. You can rename a management group all day but the underlying ID stays whatever you typed when you created it.

Moving a subscription between management groups requires Owner on both the source and the destination, plus a full re-evaluation of every inherited policy and role assignment. In a regulated environment, that re-evaluation is an auditable event. Multiply by a hundred subscriptions and the "cleanup" project becomes a program.

Policy assignments do not move with subscriptions. They stay bound to whatever scope you originally targeted. If you assigned at subscription scope to move fast on day one, you now have N copies of the same policy drifting independently.

Tenant Root is a special case. It requires elevated access to manage, most automation pipelines don't have it, and most organizations touch it exactly once — usually badly.

Now the mistakes.

Organizing by business unit instead of workload archetype

This is the most common one, and the one that hurts the most when it bites. Business units reorganize constantly. Workload archetypes Platform, Corp, Online, Sandbox, Decommissioned are stable. If your hierarchy mirrors the org chart, every reorg becomes a governance migration.

The pattern I keep seeing: a BU gets renamed, absorbed, spun out, or split. The MGs underneath it now reference an organization that no longer exists. Policy assignments are bound to those scopes. RBAC is bound to those scopes. The IaC pipeline that vends new subscriptions has the old BU baked into its module inputs. You can fix it, but you're touching every layer at once, and the audit team wants to know why every policy assignment in the tenant just churned.

Archetypes don't reorg. A platform subscription is a platform subscription whether Wealth Management still exists as a BU or not.

No intermediate root management group

Skipping the intermediate root, the single "contoso" MG that sits directly under Tenant Root looks tidy on day one. Why add a layer that only has one child?

You add it because Tenant Root is hostile to normal operations. It requires elevated access, it's awkward to target from automation, and it's the wrong scope for almost everything except the handful of policies that genuinely need to apply tenant-wide. Without an intermediate root, every "apply this to everything" policy goes on Tenant Root, and now your change pipeline needs elevated access to do routine work.

Retrofitting an intermediate root is possible, but it means re-scoping every assignment that landed at Tenant Root, and in most tenants nobody is fully sure what's there or why.

Encoding mutable meaning in MG IDs

The object wealthmanagement-bu-mg looks fine the day you create it. Three years later Wealth Management has been absorbed into Private Banking, the display name has been updated, and the resource ID still says wealthmanagement. Every policy assignment, every IaC reference, every audit report, every ticket all pointing at a name that no longer matches reality.

Keep IDs structural and stable. platform-connectivity-mg is fine. archetype-online-mg is fine. bu-mg anything-mutable will come back to haunt you. The display name is where human-readable, change-friendly labeling lives.

Mixing platform and workload subscriptions under the same MG

Connectivity, identity, and management subscriptions have policy needs that directly conflict with workload subscriptions. The hub subscription holding a Palo Alto VM-Series needs public IPs and permissive outbound rules; workload subscriptions should be denying both of those by default. If platform and workload share an MG, every workload-restrictive policy needs an exclusion for the platform subs, and exclusions are where governance quietly dies. Each exclusion is a small judgment call, and judgment calls accumulate into a policy surface no one fully understands.

Separate Platform from Landing Zones (workloads) at the top of your hierarchy. This is the one structural decision worth getting right even if you cut corners everywhere else.

No Decommissioned management group

When a subscription is being wound down, it needs somewhere to go that has restrictive policy and clear ownership. Without a Decommissioned MG , subs in wind-down sit in their original MG, still inheriting normal policy, still accepting new resources, still accumulating cost and risk until someone finally notices six months later.

The good news: this one you can usually add without much pain. Create a Decommissioned MG with deny-by-default policy, move subscriptions there as part of your offboarding runbook, and you've closed a real gap. The bad news: the subscriptions that needed it most are usually already a mess by the time you build it.

 Going too deep

Azure supports six levels of management group nesting. Useful depth is three, maybe four. Past that, policy inheritance becomes genuinely hard to reason about, effective permissions take real effort to compute, and new joiners on the platform team can't hold the structure in their head.

Depth feels like organization. It mostly produces confusion. If you find yourself adding a fifth level to express a distinction, the distinction probably belongs in policy parameters, tags, or naming; not in the hierarchy.

 Policy assignments at subscription scope instead of MG scope

This one is tempting because it's faster on day one. A workload team needs an exception; you assign the policy directly to their subscription rather than restructuring the MG hierarchy. Repeat fifty times and you have fifty independent assignments of nominally the same policy, each capable of drifting, none doing the work the hierarchy was supposed to do.

Assign at the highest scope where the policy is true, and use parameters and exclusions for the genuine exceptions. If a subscription needs a different policy posture than its siblings, that's a signal it might belong in a different MG; not a signal to bypass the hierarchy.

What you actually can fix without bleeding

Not everything is permanent. A few things you can clean up incrementally:

Display names can be changed freely but just remember the IDs don't move. Adding a Decommissioned MG and migrating wind-down subscriptions into it is usually low-risk. Splitting Platform out from workloads is doable if you catch it in the first year or so, before too much policy is bound to the mixed parent. Promoting subscription-scoped assignments to MG scope is fine if you accept a brief window of duplicate assignment while you transition.

Everything else, the archetype-versus-BU choice, the intermediate root, the encoded names, those are decisions you live with.

The principle worth internalizing

The teams that get this right aren't smarter or better resourced. They simply refused to encode anything mutable into the structure from the start. Design around archetypes, not org charts — because org charts change with every reorg, and your management group hierarchy shouldn't have to follow them. Use stable, semantically meaningful IDs, keep the platform layer cleanly isolated from workloads, and always include a designated landing zone for end-of-life subscriptions so decommissioned workloads have somewhere to go that isn't polluting your active scopes. Assign policy at the highest scope where it's universally true, and resist the temptation to push it lower just because a specific team asked for an exception today.

Everything else in your Azure estate is recoverable with enough time and effort. The management group hierarchy is not — reshaping it after workloads are deployed means touching policy assignments, RBAC inheritance, subscription moves, and every automation that assumed a stable path. Design it like it has to last a decade, because for most organizations, whether they planned for it or not, it will.