The subscription moves tenants, the resources come — the access does not

You can change the Microsoft Entra directory a subscription belongs to, and every VM, disk, and database goes with it. What stays behind is everyone's permission to touch those things. That gap is the whole story of a tenant move.

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

This is one chapter of the Azure tenant-to-tenant migration guide, and it is the Azure-resource half of it. A subscription is a billing and resource container, but it is also pinned to exactly one Entra tenant, and that tenant is where the identities live — the users, the groups, the service principals, the role assignments that decide who can do what. When you transfer the subscription to a new directory, the resources travel with it intact. The identity plane does not. Microsoft is blunt about it: all role assignments and custom roles in Azure RBAC are permanently deleted from the source directory and are not carried across.

What the move actually does

There are two operations that look similar and are easy to confuse. You can transfer billing ownership of a subscription to another account and leave it in the same tenant — nothing about access changes. Or you can move the subscription's directory, which is the operation in play here. In the portal's billing transfer flow this is a checkbox, "Move subscription tenant"; if you clear it, existing role assignments are kept, and if you check it, they are wiped. Associating an already-owned subscription with a different tenant does the same directory move without touching billing. Either way, the subscription ID stays the same, the resources stay in place, and the tenant they answer to is what changes.

The compute follows the subscription. The permission to reach it stays in the tenant you left.

So after the move, the subscription is sitting in the target directory with all its resources present and only one human able to see them: the person who accepted the transfer. Everyone else's access is gone, because their role assignments referenced principals in the old tenant, and those references no longer resolve. This is not a bug. It is the security model doing exactly what it should — a directory boundary is a trust boundary, and you do not get to carry the old tenant's grants into the new one.

Why identities break and resources don't

A role assignment is a three-part fact: this principal, this role, at this scope. Delete the tenant that owns the principal from the picture and the assignment is meaningless, so Azure removes it. Custom role definitions go the same way. You re-create both in the target tenant, mapping each old user, group, or service principal to its counterpart in the new directory.

Managed identities are the sharper edge. A managed identity is a service principal, and it was born in the source tenant. Move the subscription and the identity is orphaned — it points at a directory the subscription no longer belongs to. For a system-assigned identity you disable it and re-enable it, which mints a fresh principal in the new tenant; for a user-assigned identity you delete it, re-create it, and re-attach it to the resource. Then you re-grant its roles. Until you do, a VM that stops and restarts can fail to come up, because it is still holding the stale identity reference.

Key Vault deserves its own warning. A vault is tied to the tenant ID of the subscription it was created in, and every access policy is tied to that tenant too. After the move you update the vault's tenant ID, strip the old access policies, and add new ones. The danger case: if a storage account or SQL database uses that vault for encryption at rest, a broken vault dependency during the move can be unrecoverable. Microsoft's advice is to swap to a different key vault or disable customer-managed keys before you move, not after.

The things that cannot come at all

Some resources are not merely reset — they are flagged as not recoverable across a tenant move, and you need to know which before you commit. Microsoft lists Azure Kubernetes Service, Microsoft Entra Domain Services, Azure Databricks, Microsoft Dev Box, and Azure Deployment Environments among the ones you cannot bring across; the guidance for several is to re-create them in the target. SQL Database, MySQL, and PostgreSQL with Entra authentication enabled block the move — you disable Entra auth, move, then turn it back on. Azure Policy objects, including custom definitions and compliance history, do not survive and must be re-exported and re-assigned. Service Fabric clusters get re-created. And CSP subscriptions cannot change directory at all. One more caveat worth stating plainly: removing role assignments does not necessarily remove access. Storage account keys, management certificates, and remote-access credentials still work after the move, so if the point of the move is to cut the old tenant off, rotate those too.

The takeaway

Transferring a subscription to another tenant moves the container and everything in it, then severs every grant that said who could use it. Plan it as an access-rebuild project, not a copy: inventory your role assignments, custom roles, managed identities, and Key Vault policies before you touch the checkbox, confirm none of your critical services are on the cannot-move list, and expect downtime while you wire access back up in the new directory. The resources are the easy part. The identity plane is the work, and it is the part that, done sloppily, locks you out of your own subscription.

Questions people also ask

What happens to role assignments when you transfer an Azure subscription to another tenant?

Every Azure RBAC role assignment and every custom role is permanently deleted from the source directory and is not carried over. Only the user who accepts the transfer keeps access. You have to map the old users, groups, and service principals to objects in the target tenant and re-create the assignments there by hand, which is why you export them first.

Do resources move with the subscription when you change its directory?

Yes. The subscription and all its Azure resources stay put and travel with it to the new tenant — the VMs, disks, storage accounts, and databases are all still there. What does not travel is the identity plane: the role assignments, managed identities, and Key Vault tenant trust that decided who could touch those resources. The compute follows, the access does not.

Why do managed identities break after a subscription transfer?

A managed identity is a service principal that lives in the tenant. Move the subscription and that identity is left behind in the old directory, so it no longer resolves. System-assigned identities have to be disabled and re-enabled to mint a fresh one in the new tenant; user-assigned identities have to be deleted, re-created, and re-attached. In both cases you then re-create their role assignments.

Does Azure Key Vault keep working after moving to a new tenant?

No, not without intervention. A key vault is bound to the tenant ID of the subscription it was created in, and every access policy is tied to that tenant too. After the move you update the vault's tenant ID, remove the old access policies, and add new ones for the target tenant. If a storage account or database uses that vault for encryption at rest, plan carefully — a broken dependency here can be unrecoverable.

Which Azure services cannot be transferred to a different directory?

Microsoft flags several as not recoverable across a tenant move: Azure Kubernetes Service, Microsoft Entra Domain Services, Azure Databricks, Dev Box, and SQL, MySQL, or PostgreSQL with Entra authentication enabled. CSP subscriptions cannot change directory at all. For SQL family databases you disable Entra auth first, move, then re-enable; for AKS and Domain Services the guidance is to re-create.