Move Azure resources to another tenant — and what does not move
A director asks you to hand a set of Azure resources to a company you just acquired, in their tenant. You open the portal looking for a "move to another tenant" button. It isn't there — because that operation does not exist, and the thing you actually move is bigger than a resource.
New to cloud? CAMPUX is a free, build-first course. Start here →
You don't move most Azure resources directly across a tenant boundary — no such operation exists. You transfer the whole subscription to the new Entra tenant so its resources ride along, or you recreate and redeploy them. RBAC assignments, managed identities, and Key Vault access break, because they're tied to the old tenant's Entra directory.
This is part of the Azure tenant-to-tenant migration guide, and it is the piece that trips up the most people, because the mental model everyone brings is wrong. You picture picking a VM, a storage account, a database, and shipping them to a different Microsoft Entra tenant one by one. Azure has no such operation. Resource Manager can move resources between resource groups and between subscriptions, but the moment you want them under a different tenant, the whole framing changes.
The subscription is the unit that crosses the boundary
Fix this reality in your head before anything else. The subscription is what belongs to a tenant. Every resource lives inside a subscription, and every subscription is associated with exactly one Microsoft Entra directory. So there is no "move this resource to tenant B" — there is only "move this subscription to tenant B, and all of its resources come along." Microsoft's own transfer process is written entirely at the subscription level: you transfer the subscription to a different directory, and the resources ride inside it. The mechanism for that hop is covered in transferring the subscription; this note is about why that is the only door and what falls off along the way.
That has a blunt consequence. If you only want some of the resources in a subscription to end up in tenant B, you cannot slice them off and send just those. You either move the entire subscription, or you separate the resources you want into their own subscription first (a same-tenant operation), and then transfer that subscription. There is no way to peel individual resources across the boundary.
The same-tenant move is a different operation entirely
People confuse this constantly, so be precise. Azure absolutely lets you move resources between resource groups, and between subscriptions — with az resource move, Move-AzResource, or the portal's Move button. But Microsoft's requirement is flat: for a cross-subscription move, "both subscriptions must be part of the same Microsoft Entra ID tenant." The tool checks the two tenant IDs and refuses if they differ. So a subscription-to-subscription move reorganizes your estate inside one tenant. It never changes which tenant owns the resources. When someone says "I moved the resources to another subscription," ask the question that matters: same tenant, or different one? Only the second is a tenant migration, and only a subscription transfer performs it.
There is no per-resource move across tenants. You move the subscription, and the resources follow.
What does not survive the hop
The resources come across, but a lot of what makes them work does not — because that machinery is tied to the source Entra directory, and the directory is exactly what you are leaving behind. Microsoft is direct about the biggest one: when you transfer a subscription, "all role assignments and custom roles in Azure role-based access control (Azure RBAC) are permanently deleted from the source directory and aren't transferred to the target directory." Permanently. Nobody has access on the far side until you rebuild it.
Managed identities break the same way. They are Entra objects, so they do not get updated when the subscription changes tenants — system-assigned identities have to be disabled and re-enabled, and user-assigned identities have to be deleted, re-created, and re-attached, with every role assignment rebuilt. Key vaults keep the old tenant ID and every access policy, so you update the tenant ID and rewrite the policies before anything can read a secret. And a set of deeply Entra-integrated services do not transfer at all: AKS clusters, Azure SQL or MySQL with Entra authentication enabled, Microsoft Entra Domain Services, and Azure Databricks workspaces are all on Microsoft's "cannot transfer" list. Those you rebuild in the target tenant, not move.
If a storage account or SQL database uses customer-managed keys backed by a key vault that is part of the transfer, Microsoft warns this "can lead to an unrecoverable scenario." The identity that opens the data and the vault holding the key both shift under you at once, and the data can become unreadable. Before you move, either point those resources at a different key vault or temporarily disable customer-managed keys. This is the one that turns a migration into a data-loss incident, so check it before anything else.
| Item | Survives the move? | What you must do |
|---|---|---|
| The subscription itself | Yes — it is the unit that crosses | Transfer it to the target Entra directory; it keeps its subscription ID. |
| Resources and data | Mostly — they ride inside the subscription | Nothing for the resource shells; keep their resource IDs. Verify each service after arrival. |
| RBAC role assignments | No — permanently deleted from the source | Export every assignment and custom role first, then re-create them all in the target. |
| Managed identities | No — they are tied to the old directory | Re-enable system-assigned ones; delete and re-create user-assigned ones, then reattach their roles. |
| Key Vault access policies | No — the vault keeps the old tenant ID | Update the vault's tenant ID and rewrite every access policy before any secret can be read. |
| Entra users and groups | No — they do not travel with the subscription | They live in the target tenant already or get provisioned there; remap identities to the new principals. |
The approach that works: inventory, then rebuild
Because so much is Entra-bound, treat a tenant transfer as inventory-then-rebuild rather than a single click. Before you touch anything, export the full picture from the source: every role assignment, every custom role definition, the list of managed identities and what they had access to, your key vault access policies, and the resources flagged by Azure Resource Graph as having a tenant or identity dependency. Microsoft's transfer guide gives you the exact CLI to dump each of these to a file. That export is your rebuild manifest for the target tenant.
Then decide, per service, whether it transfers with the subscription or has to be re-created fresh. The Entra-integrated ones on the "cannot transfer" list get rebuilt in tenant B and their data copied over — often a parallel-environment approach where you stand up the new side, cut users across, and decommission the old. Everything else transfers with the subscription and gets its access rewired on arrival. And plan for downtime: any configuration keyed on identity changes during the move, so this is not a zero-impact operation no matter how carefully you stage it.
The takeaway
Azure has no per-resource "move to another tenant." The subscription is the unit that crosses the boundary, and its resources ride along inside it — while RBAC, managed identities, Key Vault access, and every Entra-integrated service either get wiped or refuse to come. Moving resources between resource groups or subscriptions in the same tenant is a routine, unrelated operation; do not let the shared word "move" fool a stakeholder into thinking a cross-tenant hand-off is the same thing. Inventory what depends on the source directory, decide what transfers versus what you rebuild, guard the customer-managed-key case, and budget for downtime. Do it in that order and the hand-off ends with the resources running under the new tenant and the data intact, which is the only version of this migration anyone remembers fondly.
Questions people also ask
Can you move a single Azure resource to another tenant?
No. Azure Resource Manager has no operation that moves an individual resource to a subscription in a different Microsoft Entra tenant. The move you can run relocates resources between resource groups or subscriptions, and both subscriptions must sit in the same tenant. To cross a tenant boundary you move the whole subscription, or you rebuild the resource in the target tenant and copy its data over.
How do you move Azure resources to another tenant?
You transfer the subscription that contains them to the target Microsoft Entra directory. Every resource under that subscription moves with it in one operation, keeping its subscription ID and resource IDs. The alternative is to build the resources fresh in the target tenant and migrate data. There is no third path that moves resources one at a time across the boundary.
What is the difference between moving resources between subscriptions and moving them to another tenant?
A subscription-to-subscription move inside one tenant is a normal Resource Manager operation, but both subscriptions must belong to the same Microsoft Entra tenant. Crossing to a different tenant is a different thing entirely: you transfer the subscription to the new directory. People conflate the two because both are called moving, but only the subscription transfer changes tenants.
What breaks when you transfer a subscription to a new tenant?
All role assignments and custom roles are permanently deleted from the source directory. Managed identities break, so system-assigned ones must be re-enabled and user-assigned ones deleted and re-created. Key vaults keep the old tenant ID and their access policies must be rebuilt. Anything with deep Entra integration, such as AKS or Entra-authenticated SQL, may not transfer at all.
Do managed identities survive an Azure tenant transfer?
No. Managed identities are Entra objects tied to the source directory, so they do not get updated when the subscription changes tenants and they stop working. After the transfer you re-enable each system-assigned identity, and you delete and re-create each user-assigned identity, then re-create every role assignment those identities had. Plan for that rebuild before you move anything.