Your policies don't cross the tenant line: consolidating management groups after a merger

Two companies merge, and someone signs off on moving a workload subscription into the surviving tenant. The resources arrive. The governance that used to wrap them does not. This is part of the Azure tenant-to-tenant migration guide, and it is the piece people forget until an auditor asks why the transferred subscription has no policy on it.

New to cloud? CAMPUX is a free, build-first course. Start here →

Here is the mental model that trips everyone up. Management groups, and the policy and initiative assignments hanging off them, live inside a tenant. They sit above subscriptions, and each tenant has exactly one hierarchy that folds up into a single root management group whose ID is the tenant ID itself. A subscription is the thing that moves between tenants. The management group scaffolding around it does not move with it. So when you complete the subscription transfer, the subscription lands in the target directory, and the target defaults it straight under the target's root management group.

How inheritance actually decides what applies

Azure governance cascades downward. A policy assigned at a management group inherits to every nested management group, subscription, and resource beneath it, and the subscription owner cannot bypass it. That is the whole appeal of the structure: you assign once, high up, and everything below is covered. But inheritance is evaluated from wherever the subscription currently sits. Move a subscription to a new parent and it immediately loses every policy, initiative, and role assignment it drew from the old parent, and gains everything cascading down from the new one. Nothing about the source hierarchy is copied across the tenant boundary. It is left behind, still governing subscriptions that stayed in the source tenant, doing exactly nothing for the one that left.

The subscription arrives naked, sitting under a root that assumes nothing about it.

One detail worth internalizing: although you assign policy at the management group level, only resources at the subscription and resource-group level are evaluated. The management group is the scope you attach the assignment to, not the thing being checked. So the moment the transferred subscription changes parents, the set of assignments reaching its resources changes with it, silently, on the next evaluation cycle.

What lands under the root, and what that means

Newly arrived subscriptions default to the target root management group. Anything assigned at that root applies to the entire directory, so a responsible target tenant keeps root assignments to the bare minimum. The practical effect is that your transferred subscription now inherits only whatever thin baseline the target root carries, plus nothing else, because it is not yet parked under any of the target's purpose-built management groups. If the source tenant enforced allowed regions, required tags, diagnostic-log routing, and a security baseline through an initiative on a "Corp" or "Landing Zones" group, none of that is in force anymore. The resources are compliant with a policy set that no longer touches them.

Rebuilding the hierarchy in the target

The work is deliberate, not automatic. Stand up (or reuse) the management group structure the subscription belongs in on the target side, then move the subscription from the root down to the right parent. Moving between management groups needs write permission on the child, the target parent, and the current parent, though the root is exempt because it is the default landing spot. Once the subscription is under the correct group, reassign the initiatives that used to cover it. Reassigning an initiative is cleaner than reassigning a pile of individual policies, because you can extend the initiative later without adding assignments to manage.

Then handle remediation. Reassigning an audit policy is done the moment you save it. Reassigning a DeployIfNotExists or Modify policy only fixes new resources going forward; the resources that arrived non-compliant stay non-compliant until you run a remediation task against them. For assignments scoped to a management group, Microsoft has you create that remediation task after evaluation determines compliance, not inline with the assignment. So the order is: recreate the assignment, wire up and permission its identity, let evaluation run, then remediate the backlog.

Align to the target landing zone, not the old one

The temptation is to rebuild the source tenant's governance verbatim in the target. Resist it. The target has its own landing-zone design, its own naming, its own initiative for regions and tags and logging, and the merged subscription should conform to that, not carry a transplanted copy of the old rules. Treat the migration as the moment to fold the workload into the target's model: park it under the management group whose baseline it should obey, let inheritance do the enforcing, and reconcile any genuinely unique requirements as additions to the target's initiatives rather than a parallel hierarchy nobody else maintains.

The takeaway

A transferred subscription brings its resources and leaves its governance behind. It lands under the target root management group, inherits only what cascades from there, and every source management-group policy assignment stops applying — with DeployIfNotExists and Modify assignments doubly broken because their remediation identities were service principals in the old tenant. The fix is not a copy-paste. Rebuild the target hierarchy, move the subscription under the right parent, reassign the initiatives, recreate and permission their managed identities, and run remediation to clear the backlog. "The policies live in the tenant, not on the subscription" is the sentence that keeps a merger from shipping an ungoverned workload into production.

Questions people also ask

Do management group policy assignments move with a subscription?

No. Management groups and their policy assignments live inside a tenant, above subscriptions, and they do not travel. When a subscription is transferred to another tenant it lands under that tenant's root management group and inherits the target hierarchy instead. The source's management-group assignments are simply left behind and no longer apply to the moved subscription.

What happens to a subscription when it moves to a new management group?

It immediately loses every policy, initiative, and role assignment inherited from its old parent and gains everything inherited from the new one. Inheritance is evaluated from the current position in the hierarchy, so the governance a subscription is subject to is whatever cascades down from its new parent management group and the root above it.

Why do DeployIfNotExists policies stop working after a tenant move?

DeployIfNotExists and Modify assignments remediate through a managed identity tied to the assignment, and that identity is a service principal in the source tenant. When the subscription crosses into the target tenant the identity does not follow it, so any remediation the old assignment performed no longer runs. You recreate the assignment in the target and grant its new identity the required roles.

Does Azure Policy evaluate resources at the management group level?

You assign policy at a management group, but only resources at the subscription or resource group level are evaluated. The management group is the scope you assign at; evaluation happens on the subscriptions and resources beneath it. That is why a subscription changing parents changes which assignments reach its resources.

How do I rebuild governance in the target tenant after a migration?

Recreate the management group structure you need in the target tenant, move the transferred subscription under the right parent, and reassign the initiatives that used to cover it. For any DeployIfNotExists or Modify assignment, create a fresh managed identity and grant it the roles the definition requires, then run a remediation task to bring existing resources back into compliance.