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 cannot move an Azure resource across a tenant boundary. Microsoft states it flatly: "moving resources across Microsoft Entra tenants isn't supported." To migrate Azure resources to another tenant you transfer the whole subscription to the target Entra directory, and the resources ride along inside it — while RBAC, managed identities, Key Vault access and Azure Policy are left behind.
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. When you set out to migrate Azure resources to another tenant, 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.
Transfer the subscription to the target Entra directory — that is the whole "move." Everything else is rebuild work: export every RBAC assignment and custom role before you start, because they're deleted from the source directory on transfer; re-enable or re-create every managed identity; rewrite Key Vault access policies under the new tenant ID; and plan to rebuild, not transfer, anything deeply Entra-integrated like AKS or Entra-authenticated SQL. Budget downtime for the cutover — this is never a zero-impact move.
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.
Not every resource type supports even the same-tenant move
Check the type before you plan the work. Microsoft keeps a per-type table — resource group move, subscription move, region move — and a type marked no in the subscription column cannot cross subscriptions at all, tenant boundary or not. Child resources are not listed separately because they travel with their parent; if the parent cannot move, the child cannot either. Model the move first with the validateMoveResources action, which validates without moving anything. Three operational facts catch people out: Resource Manager rejects a request containing more than 800 resources immediately, it locks both the source and destination resource groups for up to four hours while the move runs, and role assignments do not travel with a moved resource — they are orphaned and you re-create them afterwards. A resource group itself cannot be moved to another subscription; you move its contents into a resource group that already exists on the other side.
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.
The list is longer than most people expect, and it is not all identity. Azure Policy does not come with you: every definition, assignment, exemption and the compliance history behind them is gone, so you export the definitions, import them, and re-assign. Resource locks have to be exported by hand before the move. Microsoft Sentinel workspaces are offboarded the moment the subscription lands, and the data survives only if you re-onboard them in the new tenant within 90 days. Microsoft Dev Box, Azure Deployment Environments and Service Fabric clusters cannot be transferred at all. Microsoft is candid about its own table: resource types keep changing, so treat it as the known dependencies rather than the complete set.
Two gates sit in front of the move. You need the Owner role on the subscription in the source directory, assigned directly — not inherited through a group, not carrying conditions, not activated through Privileged Identity Management — plus an account in both directories, and billing account ownership if the billing moves too. And if the subscription came through a Cloud Solution Provider, stop: changing the Microsoft Entra directory for a CSP subscription is not supported. There is also a way out of moving at all. Azure Lighthouse lets people in the target directory manage the subscription where it already sits, which keeps every role assignment, identity and vault intact. If the reason for the move is management convenience rather than ownership, that is usually the cheaper answer.
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. |
| Azure Policy objects | No — definitions, assignments, exemptions and compliance data are lost | Export the definitions before the move, import them in the target, then re-assign and re-create exemptions. |
| Resource locks | No — they are not carried across | Export the locks by hand from the portal or CLI first, then re-apply them after arrival. |
| Microsoft Sentinel workspaces | Offboarded immediately on transfer | Re-onboard in the new tenant within 90 days and the workspace keeps its Sentinel data. |
| 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. |
How to migrate Azure resources to another tenant: 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.
Azure tenant migration: what the whole project covers
Search for an Azure tenant migration and you get two different projects wearing one name. The Azure half is what this note describes: subscriptions, the resources under them, and the identity plane that has to be rebuilt around them. The Microsoft 365 half is mailboxes, OneDrive, SharePoint, Teams and devices, and it runs on a separate toolset — the cross-tenant mailbox, OneDrive and SharePoint migrations, or the Migration Orchestrator when those workloads move together in coordinated batches. A merger or acquisition means both halves run at once, on one calendar, which is why a tenant migration feels bigger than the sum of its steps.
Name the workstreams and treat them separately, because each has its own tooling and its own failure mode:
- Control plane. Transferring the subscription, then re-creating role assignments, custom roles and managed identities on the far side.
- Identity. The Entra ID cutover itself, plus guest and B2B accounts, MFA methods, and hybrid identity and Entra Connect where servers still sync on-premises accounts.
- Governance. Azure Policy and management group consolidation, which is what the policy export above feeds, and naming and tagging reconciliation once two estates share one subscription list.
- Data and network. Cross-tenant storage account data migration for anything you rebuild rather than transfer, and virtual networks and hybrid connectivity where the two estates have to reach each other.
- Microsoft 365 workloads. Mailbox migration prerequisites, OneDrive user data, SharePoint, Teams, Intune devices and license mapping.
- Sequencing and safety. Coexistence or big-bang cutover, the runbook and cutover calendar, DNS cutover, rollback planning, and the cost of consolidating two tenants.
The Azure workstream goes first for anything infrastructure-shaped, because the subscription transfer is what makes those resources visible to administrators in the target tenant at all. Everything downstream — rebuilding RBAC, re-pointing pipelines, reissuing credentials — waits on it.
Can you migrate one Azure tenant into another tenant?
Not as an object. A Microsoft Entra tenant is not something you move, and there is no operation that merges tenant A into tenant B. When someone asks to migrate an Azure tenant to another tenant, what they are describing is a consolidation: transfer the subscriptions one at a time, re-create the identity and governance objects the transfer deleted, rebuild the services that cannot transfer, migrate the Microsoft 365 data workload by workload, release the custom domains from the source tenant and verify them in the target, and retire the source tenant once it is empty. Microsoft frames its own half the same way — you migrate an existing tenant to a new tenant, in the shape of a merger, a divestiture, a consolidation, or an internal reorganization.
The practical consequence is a sequencing problem, not a button. Subscriptions transfer one at a time, which gives you a phased path: move the least coupled subscription first, rebuild its access, prove the pattern, then work up to the ones carrying production. None of that is instant, and Microsoft warns outright that a transfer can require downtime. Treat any plan that promises a tenant migration over a single weekend with suspicion unless the estate is genuinely small.
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.
What is an Azure tenant migration?
It is the project of moving a subscription, and everything under it, from one Microsoft Entra tenant to another. In practice that means transferring the subscription itself, then rebuilding everything tied to the old directory: RBAC role assignments, managed identities, Key Vault access policies, Azure Policy objects, and any Entra-integrated service that cannot transfer at all. The resources ride along for free; the identity plane is the actual migration work.
How do you migrate an Azure tenant to another tenant?
You migrate its contents, in order. Transfer each subscription to the target Microsoft Entra directory. Re-create the role assignments, custom roles, managed identities, Key Vault access policies and Azure Policy objects that were deleted on the way. Rebuild the services that cannot transfer. Migrate the Microsoft 365 workloads with their own cross-tenant tools. Release the custom domains from the source and verify them in the target, then decommission the empty source tenant.
Can you merge two Azure tenants?
No. There is no operation that merges one Microsoft Entra tenant into another. A tenant is not a movable object, so a consolidation is really a set of migrations: subscriptions are transferred, identity and governance objects are re-created in the target, Microsoft 365 data is migrated workload by workload, and the source tenant is retired once it is empty.
Which Azure resources cannot be moved to another tenant?
Microsoft lists the ones that cannot transfer with a subscription: Azure Kubernetes Service clusters, Microsoft Entra Domain Services managed domains, Azure Databricks workspaces, Azure SQL and Azure Database for MySQL with Microsoft Entra authentication enabled, Microsoft Dev Box, Azure Deployment Environments, and Azure Service Fabric clusters. Azure Policy objects and Entra ID access reviews are lost as well. Each of those is rebuilt in the target tenant rather than moved.
- Transfer an Azure subscription to a different Microsoft Entra directory
- Move Azure resources to a new resource group or subscription
- Move resources across resource groups, subscriptions, or regions
- Azure resource types for move operations
- Plan a Microsoft 365 tenant-to-tenant migration
- Azure Lighthouse in enterprise scenarios