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.

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.

From the field: what actually broke when I moved an estate

I have moved a working Azure estate between tenants: App Services, Azure SQL databases, Function Apps, an Automation account, Logic Apps, and the monitoring wrapped around them, as part of a wider tenant migration that also carried a couple of hundred Windows PCs. The checklists above are correct. What they do not tell you is where the time goes, so here is the list I wish I had been handed.

The alerts did not come. This was the one that surprised me. The workloads arrived, the monitoring did not: the Azure Monitor alert rules that had been watching those resources had to be rebuilt in the target, along with the action groups they fired and the diagnostic settings that fed the workspace. Nothing tells you this has happened. The resources are there, the portal looks fine, and there is simply no alert rule pointing at them any more. Export the alert rules and action groups before you move, and treat "every alert exists in the target and has fired a test" as a gate you cannot go live without.

Logic Apps and their API connections. A Logic App is a workflow plus a set of connections, and each connection was authorised by a user or a service principal in the old directory. Those authorisations are dead on arrival. Every connection to Office 365, SQL, Key Vault or a custom connector has to be opened and re-authorised with an identity that exists in the new tenant, and the managed identity the workflow used is rebuilt like any other.

The Automation account. Runbooks and schedules move with the account, but the identity the runbooks ran as does not: the managed identity is re-enabled in the new tenant and every role it held is granted again, at the same scopes. A runbook that used to stop and start VMs at night will run, fail silently on authorisation, and leave the VMs on. Check the job history the morning after, not the week after.

App Services and Function Apps. The apps run, because the compute is untouched. What breaks is everything around them that referenced the old directory: Key Vault references in app settings until the vault's tenant is fixed; built-in authentication tied to an app registration that only ever existed in the old tenant; and any deployment pipeline that signed in with a service principal or a federated credential from the old tenant. Each of those is a new app registration, new IDs, and a pipeline change.

Azure SQL. Entra authentication has to come off before the move, which the docs do say, but the part to plan for is the other side: the Entra admin on each server must be set again to a principal in the new tenant, and every contained database user that mapped to an old-tenant group has to be recreated, or the applications that used managed identity to reach the database will be refused.

None of this is exotic. It is the same fact repeated: the resources moved, and everything that named an identity did not. Budget the identity work as the project, and the move itself as a checkbox.

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.

Every class is open to read. A free account saves your progress. Azure resources used for labs may incur charges.