Business Challenge
A mid-sized software company is acquired. The integration plan is unremarkable and someone writes the obvious line into it: move the acquired company's Azure subscriptions into the parent's Microsoft Entra tenant, so that one directory governs everything and the acquired staff sign in with their new accounts.
It reads like an administrative change. The resources are not moving. No virtual machine is rebuilt, no database is migrated, no address range changes. The subscription keeps its ID, so the applications that reference it keep working.
What actually happens on the day is this. Every role assignment in the subscription is permanently deleted — not migrated, not archived, deleted. Every custom role goes with them. Every system-assigned managed identity stops working and has to be disabled and re-enabled; every user-assigned managed identity has to be deleted, re-created and re-attached to the resource that used it. Every key vault becomes inaccessible until its tenant ID is updated and its access policies are rebuilt. All Azure Policy definitions, assignments, exemptions and compliance history are gone and must be exported and re-created. And the two AKS clusters cannot make the move at all: a cluster cannot be transferred to a different directory, full stop.
None of that is a bug, and all of it is documented. It follows from a single structural fact that most teams never have to think about: the directory is not inside the subscription. The subscription trusts it.
The fastest way to see that these are two separate planes: a Global Administrator in Entra ID has no access to any resource in any subscription by virtue of that role. And it works in the other direction too — when the owner of a subscription joins it to an existing tenant, that owner is not assigned Global Administrator. Directory power and resource power are granted separately, and people usually discover this at the worst moment, when nobody in the room can do the thing that needs doing.
Architecture
Every Azure subscription has a trust relationship with exactly one Microsoft Entra tenant. The tenant supplies the identities; the subscription supplies the resources and the role assignments that point at those identities. A subscription can trust only a single directory, while one directory can be trusted by many subscriptions.
What lives in the directory
Users, groups, service principals and app registrations. Managed identities, which are service principals with a lifecycle tied to an Azure resource. And Entra roles — Global Administrator, User Administrator, and the rest — which control access to directory objects: users, groups, domains.
A directory has its own identity independent of any subscription. Every new Entra directory gets an initial domain name of the form contoso.onmicrosoft.com, and custom domains are added to it afterwards. A user has one home directory for authentication, but can be a guest in many others.
What lives in the subscription
Resources, resource groups, and Azure RBAC role assignments. A role assignment is a pointer: it names a principal in the trusted directory, a role definition, and a scope. That pointer is the entire connection between the two planes, and it is stored on the subscription side.
This is why the two-plane model matters more here than the equivalent question in other clouds. The identity is not in the subscription. The permission is. Break the trust and the permissions are pointing at principals the subscription can no longer resolve — which is precisely why they are deleted rather than carried across.
Which way the trust runs
The subscription trusts the tenant, not the other way round. The practical consequences:
- Adding a subscription to your tenant gives you no power over that subscription's contents until somebody assigns you an Azure role in it.
- Being Global Administrator of the tenant does not let you read a storage account. It lets you elevate yourself to User Access Administrator at the root of the hierarchy, which is a deliberate, audited act — that mechanism was the subject of #1.
- When a subscription expires, the trust remains but the principals lose access to the resources.
Why This Architecture Holds Up
Almost everything in Azure can be moved with effort. A resource can move between resource groups, a resource group's contents can move between subscriptions, and a subscription can move between management groups. Those are re-parenting operations: the object keeps its identity and its permissions come along or are re-derived from a new position in the same hierarchy.
A directory change is not a re-parenting operation. It replaces the source of identity itself, and every permission in the subscription refers to principals that only exist in the old one. There is no mapping Azure could apply, because it has no way of knowing that jayanth@oldco.com and jayanth@newco.com are the same person. So it deletes.
The three tiers of damage
Deleted permanently, rebuild by hand
Every role assignment and every custom role. Export both to files before the move, because they cannot be recovered afterwards and there is no undo — the documentation says plainly that you cannot go back once the subscription is transferred.
Broken, recoverable with work
System-assigned managed identities need disabling and re-enabling. User-assigned identities need deleting, re-creating and re-attaching. Key vaults need a new tenant ID and rebuilt access policies. Storage and Data Lake ACLs need re-applying. Synapse workspaces need their tenant ID updated.
Cannot move at all
AKS clusters. Entra Domain Services managed domains. Azure Databricks workspaces. Dev Box and Deployment Environments. Service Fabric clusters must be re-created. Databases with Entra authentication enabled — SQL, MySQL, PostgreSQL flexible server — must have it disabled first, or they cannot move.
Silently still there
The part nobody plans for. Role assignments are removed, but access keys, management certificates and remote access credentials are not. Users in the source directory keep whatever access those grant until the credentials are rotated. Removing someone's role assignment is not removing their access.
If a resource uses encryption at rest with customer-managed keys, and the key vault holding those keys is part of the transfer, the documentation describes the outcome as an unrecoverable scenario. The guidance is to move the dependency to a different key vault, or temporarily disable customer-managed keys, before transferring. This is the one item on the list where careful sequencing is not an optimisation.
One time limit worth writing down
Microsoft Sentinel workspaces are offboarded immediately when the subscription transfers. They can be re-onboarded in the new tenant with the same data intact — provided that happens within 90 days. That is the only clock in the whole process, and it runs during exactly the period when everybody is busy re-creating role assignments.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| Which tenant a new subscription trusts | Decide before anything is deployed into it | It is the one attribute that cannot be changed cheaply later. Everything else in the subscription can be rebuilt in place; this cannot. |
| Merger or acquisition: one directory or two | Azure Lighthouse and a multi-directory architecture, unless there is a reason it must be one | It is the documented alternative: leave the subscription in its own directory and delegate access to users in the other. No deletion, no downtime, no rebuild. |
| If you do transfer | Export role assignments and custom roles to files first | Both are permanently deleted with no recovery path. A saved JSON file is the only version of your access model that will survive the move. |
| Who performs the transfer | An account with Owner assigned directly on the subscription | The role must not come via a group, a condition, or PIM activation. An estate that has correctly eliminated standing access has to make a deliberate exception to perform this operation. |
| Preventing surprise transfers | Set a subscription policy to block directory changes | The operation needs only subscription Owner. Anyone who holds it can move a subscription out of your governance hierarchy without touching anything you monitor. |
| Cutting off the old directory's access | Rotate storage keys, certificates and secrets as part of the cutover | Deleting role assignments does not revoke key-based access. Until keys rotate, the previous directory's users retain whatever those keys grant. |
| Directory administration and resource administration | Treat them as separate roles held by separate people | They are separate planes with separate role systems. Conflating them produces accounts that are powerful in both, which is the shape of the account an attacker most wants. |
Changing a subscription's directory is a service-level operation and does not affect billing ownership. The two are transferred separately, and a plan that assumes moving the directory also moves the invoice will leave the old account paying for it.
Closing Thought
The tenant is the one dependency in an Azure estate that behaves like a foundation rather than a component. Everything else can be rebuilt underneath a running system; the directory can only be replaced by discarding the authorisation layer and building it again.
Which makes the useful habit an early one: when a subscription is created, know which directory it trusts and why, and write down the reason. It is a decision that takes a minute at the start and a project to revisit.
#3 gets into Azure RBAC properly: role definitions, role assignments, and why the scope of an assignment matters more than the role in it — the mechanism this post has been pointing at from the subscription side.
Comments