Moving OneDrive between tenants: the files are easy, the sharing is the work
The bytes move themselves, quietly, without ever leaving the Microsoft cloud. The part that goes wrong is everything around them: who owns the moved OneDrive on the other side, and whether the links people already sent still open.
New to cloud? CAMPUX is a free, build-first course. Start here →
When two companies merge or one gets carved out, someone has to move a few thousand users' personal files into a new Microsoft 365 tenant. That is what cross-tenant OneDrive migration is for, and it is one leg of the wider Azure tenant-to-tenant migration guide. The reassuring part first: the actual content move is well-behaved. An admin uses SharePoint Online PowerShell to establish a trust between the two tenants, then schedules the OneDrive moves. Up to 4,000 accounts can be queued at once, the data stays inside Microsoft's cloud the whole time, and each user sees only a few minutes where their OneDrive goes read-only. The hard engineering is not the copy. It is making sure the right person owns the result and that nothing they shared quietly breaks.
Identity mapping is the load-bearing step
Before you move a single file, the service needs to know exactly which source user maps to which target user. That is what Cross-Tenant Identity Mapping does: it establishes a one-to-one relationship between an account in the old tenant and its counterpart in the new one, and it writes the attributes that tie them together. Skip it and the migration has no dependable way to know that this OneDrive belongs to that person on the far side. Microsoft is blunt about the order: run identity mapping after you create the target users, and before you migrate any data. Get the order wrong and you are cleaning up ownership by hand across thousands of accounts.
The copy is a solved problem. Ownership is the problem you are actually being paid to get right, and it is decided before the first file moves.
The target account has to be real, licensed, and empty
Three conditions on the target, and all three trip people up. First, every user and group you intend to migrate must be precreated in the target tenant before the move — the destination account cannot be conjured mid-migration. Second, each of those target users needs the right license assigned, and the migration itself requires a Cross-Tenant User Data Migration license, which you can attach to either the source or target user object. Third, and this is the counterintuitive one: the target user must not already have a OneDrive site. There is no merge. If a OneDrive was already provisioned for them, the move fails, because it will not overwrite an existing site. In practice you restrict OneDrive creation in the target tenant for the duration of the project, so nobody self-provisions a site that then blocks their own migration.
Precreate the target users and groups and license them. Restrict OneDrive site creation on the target so none get auto-provisioned. Establish and verify the trust between tenants. Run identity mapping to bind source users to target users one-to-one. Then start the content move. Every one of those steps is a prerequisite for the next — the move at the end is the easy part precisely because the four steps before it did the real work.
What happens to shared links
This is the question that decides whether users trust the migration or file tickets for a week. When an account finishes moving, Microsoft leaves a redirect at the old OneDrive location. Anyone who clicks a link that pointed at the old spot — a document shared in a chat, a link buried in an email from March — is forwarded to the new location, provided they still have access to the destination. Those redirects persist until the source tenant is deprovisioned, and an admin can remove them selectively, site by site, when you are ready. On the permissions side, the users and groups included in your identity mapping file keep their permissions on the migrated OneDrive in the target tenant. External sharing is the softer edge: a guest who had a link works only if their access still resolves in the new tenant, so external collaboration is worth spot-checking rather than assuming.
Verify, then tell people in plain words
After the move, confirm the obvious things: the target user owns their OneDrive, the file and folder counts line up, and a shared link from the old location redirects instead of dead-ending. Watch for the path-length trap — Microsoft caps the full path at 400 characters, so a deep folder tree that fit under the short source URL can spill over the longer target URL and fail. Keep target OneDrive URLs short and check the long paths in advance.
Then write the note to users in language that has no jargon in it. Something like: your files are moving to the new company account; for a few minutes your OneDrive will be read-only; when you sign in with your new account, everything will be there, and old links your colleagues sent you will still open. That sentence prevents most of the panic, because the thing users fear is that their files vanished. They did not. They are under a new name, exactly where the mapping put them.
The takeaway
Cross-tenant OneDrive migration is a copy job wrapped around an identity job, and the identity job is the one that matters. Precreate and license the target users, keep their OneDrive sites from existing early, verify the trust, and run identity mapping so each moved OneDrive lands under the correct owner. Do that and the redirects keep old links alive, permissions follow the mapping, and the move reads to users as a quiet few minutes rather than a lost afternoon. "Files are easy, sharing and ownership are the work" is the sentence of someone who has actually run one.
Questions people also ask
What is cross-tenant OneDrive migration?
It is the supported way to move a user's OneDrive content from one Microsoft 365 tenant to another during a merger, acquisition, or divestiture. Administrators use SharePoint Online PowerShell to establish a trust between the two tenants and move the accounts. The data never leaves the Microsoft cloud, and it is a one-time move, not an incremental sync.
Does the target user need to exist before the migration?
Yes. Every user and group you plan to migrate must be precreated in the target tenant and assigned the right licenses before the move runs. The one catch is the OneDrive site itself: it must not already exist on the target. If a OneDrive has already been provisioned for that user, the migration fails, because it cannot overwrite an existing site.
Why does identity mapping have to run first?
Identity mapping is what tells the service which source user corresponds to which target user, one to one. Without it, the system has no reliable way to know that the moved OneDrive belongs to the correct account in the new tenant. Microsoft is explicit that you run identity mapping after creating the target users and before migrating any data, so ownership and permissions land correctly.
What happens to sharing links after the move?
Microsoft leaves a redirect at the old OneDrive location. Anyone who clicks an existing shared link to the old spot is forwarded to the new one, as long as they still have access to the destination. Those redirects stay in place until the source tenant is deprovisioned, and an admin can remove them selectively, site by site.
Can I merge into an existing OneDrive on the target?
No. There is no merge. The target user must not already have a OneDrive site, and the migration is a single move rather than a set of delta passes. Because of that, you restrict OneDrive site creation in the target tenant during the project so nobody accidentally provisions a site that then blocks their own migration.