Moving a storage account across tenants: what travels, what breaks, what you rebuild

Someone hands you a storage account in one company's tenant and says "get it into ours." That single sentence hides two completely different jobs, and picking the wrong one costs you either a support case or a week of copying — this is part of the Azure tenant-to-tenant migration guide.

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

The word "move" is doing a lot of quiet lying here. There are two real paths, and they are not variations on a theme — they produce different end states. In the first, the account itself travels: it stays the same resource, keeps the same data, and lands in the new tenant with its identity-based access model stripped out. In the second, you never move the account at all; you stand up a fresh one in the target tenant and copy the bytes across. Which one you want depends on whether you need the account, or only what is inside it. Get clear on that before you touch anything.

Two paths, and only one keeps the account

An individual resource cannot change Microsoft Entra tenants on its own. Azure only lets a whole subscription cross a tenant boundary, so if you want the actual storage account — same name, same endpoint, same data in place — you move it by moving the subscription that holds it. In practice that often means creating a temporary subscription, moving the account into it, then transferring that subscription to the destination tenant and finally moving the account to its permanent home there. Microsoft is blunt that when the source and destination tenant IDs differ, this is a support-assisted operation, not a self-service button. Nothing is copied in this path: the blobs, files, queues, and tables sit untouched the entire time.

The second path treats the account as disposable. You create a new storage account in the target tenant and copy the data into it with AzCopy, Azure Storage Explorer, or Data Factory. The source account keeps everything until you delete it. This is the honest thing to call a copy, and it is usually the right call when the two tenants belong to genuinely separate organizations, when you want a clean account name in the new tenant, or when support-driven subscription surgery is more ceremony than the job deserves.

One path relocates the account and breaks its access; the other copies the bytes into a new one.

What the subscription move quietly breaks

Here is the part people get wrong. When the account travels with a subscription, the data survives perfectly and the access model does not. Azure RBAC role assignments are bound to identities in the source tenant, and during a tenant transfer those assignments are removed and cannot be restored. Your Storage Blob Data Contributor grants, the app registrations you gave data-plane roles, the groups you carefully scoped — gone. Managed identities do not come across either; a system-assigned identity is tied to its home tenant, so anything that authenticated as the resource stops authenticating. User-delegation SAS tokens, which are signed by an Entra identity rather than an account key, stop being valid because the identity backing them no longer holds a role on the account.

What does keep working is exactly the thing that is not identity: account keys, and the shared access signatures derived from them. A key belongs to the account, not to any tenant, so it survives the move intact. That feels like a relief and is really a trap. A key grants unconditional full access, cannot be scoped down, and cannot be governed by Conditional Access. If your apps were quietly leaning on keys, they will keep running after the move and mask the fact that your whole identity layer is now missing. Treat surviving keys as a bridge you cross once, then rebuild RBAC and rotate them.

Copying the data across tenants with AzCopy

When you go the copy route, AzCopy is the tool Microsoft points you at, and it is genuinely good: it uses server-to-server APIs, so the data streams directly between the two storage endpoints instead of routing down to your laptop and back up. The catch that trips people is authorization. AzCopy can authenticate with Microsoft Entra ID, but only when both the source and destination accounts live in the same tenant. Across a tenant boundary that door is closed, so you fall back to SAS tokens or account keys — a SAS on the source to read, and a SAS or key on the destination to write. One azcopy copy with --recursive and both URLs carrying their tokens moves an entire container.

A few sharp edges worth knowing before you run it. Your client needs network access to both accounts, so if either one has firewall rules or is locked behind a private endpoint you have to account for that path. AzCopy does not preserve blob index tags automatically — you reapply them on the destination. It also assumes the source is not changing mid-copy; run it against live, actively-written data and you will get an inconsistent snapshot. For a moving target, quiesce writes or use azcopy sync for a final catch-up pass once the bulk copy is done.

Private endpoints, and proving the copy landed

Private endpoints never migrate cleanly, on either path. They are tied to a virtual network, a subnet, and a private DNS zone that all live in the source environment, plus an approval on the storage account's side. On a subscription move the endpoint's networking stays behind; on a copy the new account simply has none. Either way you create fresh private endpoints in the target tenant's network, wire up the private DNS zone, and approve the connection. Budget real time for this — it is fiddly and it is where "the data's there but nothing can reach it" bugs hide.

And do not trust a copy you have not checked. AzCopy reports what it transferred, but verify independently: compare object counts and total bytes between source and destination, spot-check that container and blob structure matches, and confirm the properties you care about — content type, tier, tags you reapplied — survived. Only once the destination is proven and access is rebuilt do you delete the source. Deleting first, on faith, is how a migration becomes an incident.

The takeaway

Decide first whether you need the account or only the data. If you need the account, you move a subscription, the data rides along untouched, and you spend your effort rebuilding RBAC, managed identities, user-delegation SAS, and private endpoints in the new tenant while account keys keep things limping until you rotate them. If you need only the data, you copy it with AzCopy using SAS or keys across the tenant line, verify counts and bytes, re-point private endpoints, and delete the source last. The one thing you should never say out loud is that you "moved" the account when you actually copied it — that word, used loosely, is how the source gets deleted before anyone checks the destination.

Questions people also ask

Can you move an Azure storage account directly to another tenant?

Not on its own. An individual resource cannot change Microsoft Entra tenants by itself; only a whole subscription can move between tenants. So the account travels only if you move the subscription that holds it, often through a temporary subscription created just to carry it. If the tenant IDs differ, Microsoft's guidance is to open a support case rather than expect a self-service move.

Does moving a storage account move the data inside it?

If you move the subscription, yes: the account and every blob, file, queue, and table inside it stay exactly where they are, because nothing is physically copied. If instead you use AzCopy or Storage Explorer between two separate accounts, that is a copy, not a move. The source keeps its data until you delete it, and you are responsible for verifying the destination before you do.

What happens to RBAC role assignments when a storage account changes tenants?

They do not come with it. Azure RBAC role assignments live against identities in the source tenant, and during a tenant transfer those assignments are removed and cannot be restored. Managed identities and access policies also do not carry over. In the target tenant you rebuild every data-plane role assignment against the new tenant's users, groups, and service principals from scratch.

How do you copy blobs between storage accounts in different tenants?

Use AzCopy, which copies server-to-server directly between storage endpoints. Microsoft Entra authorization only works when both accounts are in the same tenant, so across tenants you authorize with a SAS token or an account key on at least one side. Generate a SAS on the source, a SAS or key on the destination, and AzCopy streams the data between them without routing through your machine.

Do account keys still work after a subscription moves to a new tenant?

Yes. Account keys and the shared access signatures derived from them are tied to the account, not to any identity in a tenant, so they keep working after the move. That is convenient and also the catch: a key is not identity, grants full access, and cannot be scoped or conditionally controlled. Treat surviving keys as a temporary bridge and move back to identity-based access once RBAC is rebuilt.