Microsoft 365 tenant to tenant migration: a practical guide
Phases, what Microsoft's native tools cover, what carries per workload, and how to run incremental passes before a clean cutover.
A Microsoft 365 tenant to tenant migration is really several migrations that happen to share a deadline: identities, mail, OneDrive, SharePoint sites, Teams and Planner each have their own API, their own limits and their own tool options. This guide sets out the phases that work, what Microsoft's native tooling covers and where it stops, what carries for each workload, and how to use incremental passes so the cutover weekend is short.
Identity migration (creating users, syncing passwords, joining devices) and mail routing are out of scope here; Microsoft, Quest and BitTitan cover those. Everything below assumes identities exist in the destination and concentrates on content.
The phases, in order
- Discovery and assessment. Inventory every site collection, OneDrive account, team, private channel and plan in the source. Run an assessment against SharePoint Online limits: paths that would exceed 400 characters at the destination, invalid characters, files over 250 GB, folders over the 5,000-item view threshold, unique permission scopes, and users who no longer exist. The migration checklist has the full list of findings.
- Identity and mapping. Confirm destination accounts exist, then build the user mapping: source UPN to destination UPN, with domain rewrites for the common case where only the suffix changes. The Migration API requires UPN logins and substitutes the System Account for anyone it cannot resolve, so unresolved users need a fallback user and a report.
- Destination design. Decide the target site structure, library names, landing folders and hub associations before copying anything. Restructuring on the way across is the main reason to use a third-party tool at all.
- Pilot. Migrate a small representative site, a handful of OneDrive accounts and one team end to end, then check timestamps, authorship, versions, permissions and Teams history with the people who own the content.
- Bulk pass. Run the full migration while the source stays live.
- Incremental passes. Re-run to pick up new and changed items. Repeat as often as the change rate requires, right up to the cutover window.
- Cutover. Make the source read-only, run a final incremental pass, redirect users, and verify.
- Verification and sign-off. Reconcile counts, review failures, export the completion report, and decommission the app registrations.
What Microsoft's native tools cover, and where they stop
Microsoft has two native routes for tenant to tenant content, and for some organisations they are enough.
| Native route | Moves | Constraints (from Microsoft Learn, May to August 2026) |
|---|---|---|
| Cross-tenant OneDrive and SharePoint migration (PowerShell) | OneDrive accounts and SharePoint sites, one-and-done, with redirects left behind | No incremental or delta passes. Up to 4,000 queued; 5 TB or 1 million items per site; destination sites must not pre-exist. Teams channels and structure not migrated; workflows and Power Platform must be recreated. Needs the per-user Cross-tenant User Data Migration licence. The SharePoint site variant is currently only available to Enterprise Agreement customers and is licensed per 100 GB moved. |
| Migration Orchestrator (public preview since 22 December 2025) | Exchange mailboxes, OneDrive, Teams 1:1 and group chats, Teams meetings | Explicitly does not migrate shared data such as Teams and channels or SharePoint sites. Per-user licence; available to EA, CSP, web direct, SMB and EDU. |
So the native path handles mail, OneDrive and personal chats for anyone, and SharePoint sites only for Enterprise Agreement customers, with no delta pass in either case. What it never handles is Teams channels with their conversations, Planner, restructuring during the move, and the incremental passes that make a short cutover possible. Those four things are the reason a tenant to tenant project usually pairs a native tool for mail with a content tool for SharePoint and Teams.
What carries, workload by workload
| Workload | Carries | Reported as not migrated or changed |
|---|---|---|
| SharePoint document libraries | Folders, files, full version history (nested oldest first so every version survives), Created, Modified, Author and Editor, content type, column values, unique permissions with users mapped and groups matched by name | Sharing links only where the API allows; links inside document bodies are not rewritten |
| SharePoint site structure | Site columns with the same internal name and GUID, content types with the same id, lists of the standard templates with settings, views, folders, items, attachments, list item version history through the Migration API, managed metadata with the term store copied and every term identifier kept, modern pages with URLs rewritten, quick launch and top navigation, subsites | Classic wiki and web part pages, discussion boards, and per-version values for person, lookup and managed metadata columns, which show the item's current value in every version. See migrating lists and content types |
| OneDrive | Everything a library carries; the destination OneDrive is provisioned automatically if missing | Needs the SharePoint User.Read.All application permission for the URL lookup. See the OneDrive guide |
| Teams standard and private channels | Team, channels, membership, channel files through the SharePoint engine, every post and reply as a native message with original author and timestamp | Reactions (appended as text), live mentions, shared channels, system messages, deleted posts, adaptive cards. See the Teams guide |
| Teams chats | Self-contained HTML archive per chat, optionally posted into a private channel | No supported API re-creates chats with original metadata |
| Planner | Plans, labels, buckets, tasks in board order, assignments, dates, progress, checklists, attachment references | Created and completed dates and people cannot be back-dated; they are recorded in the task description. See Planner migration |
Setting up both tenants
Migration traffic has to be app-only. Microsoft's guidance is to use only app-based authentication in a migration solution because user mode triggers increased throttling, and certificate credentials are throttled less than secrets. For a cross-tenant project that means one app registration in each tenant, each with a certificate, and one connection per tenant in the tool.
- Source tenant: an app with SharePoint
Sites.FullControl.Allto read libraries and versions,User.Read.Allfor OneDrive URLs, and the Graph Teams read permissions if channels are in scope. Some tenants need the Teams protected APIs form approved forChannelMessage.Read.All. - Destination tenant: the same SharePoint permissions plus
Teamwork.Migrate.All,Group.ReadWrite.All,Channel.Create,ChannelMember.ReadWrite.AllandTeamMember.ReadWrite.Allfor Teams import, andTasks.ReadWrite.Allfor Planner. - Consent propagation: after admin consent, Microsoft takes about five minutes to include new roles in tokens. Test sign-in before scheduling anything.
- One product App ID, not one per job: SharePoint measures throttling per tenant and app pair and warns against creating multiple App IDs to evade limits.
ShareShift's setup guide creates the registration, certificate and permissions with one PowerShell command per tenant and verifies the token contains the roles it needs; budget about twenty minutes per tenant.
Throughput, timing and the cutover weekend
Plan the timeline from Microsoft's published bands rather than from hope: roughly 10 TB a day for light content, 1 TB a day for medium content such as Office files, and 250 GB a day for heavy content, per tenant, with no SLA. Microsoft will not lift throttling for a migration and says a support ticket does not help. Migrations over 100 TB within 30 days need a support request from the tenant administrator in advance. Weekday daytime carries tighter limits for background apps, so schedule the bulk pass into nights and weekends in the destination tenant's region.
The bulk pass is the long part and it happens while the source is live. Because incremental passes only copy new and changed items, and because a changed file is uploaded as a new version on top of the destination history rather than replacing it, the cutover pass is usually small. A sensible sequence for the final weekend:
- Friday evening: final incremental pass on SharePoint and OneDrive while users finish up; Teams channels and Planner can be run in full since they are fast relative to files.
- Set the source read-only or remove write access, then run one more incremental pass to catch the last hour.
- Complete the Teams migration mode on each channel and team; membership is added after completion because a team in migration mode rejects membership changes.
- Verify with owners, reconcile counts against the item-level report, redirect users.
Because the tool can pause, stop after the current package and resume from a checkpoint, a throttling episode or a worker restart on Saturday does not restart the weekend; the pause and resume article explains exactly what each kind of stop keeps. And because Microsoft measures throttling per tenant and app, adding workers does not add API budget; it adds upload bandwidth and reach, which is useful when sources sit on different networks.
Verification and sign-off
Reconcile three sources of truth: the tool's item-level report (status, destination URL, error text per item), Microsoft's own per-job import logs, and the Microsoft 365 audit log, which has recorded migration events at file level such as FileUploaded since November 2024. Items Microsoft reported as failed should have been retried automatically; anything still failed needs a decision, not a shrug. The completion report article covers what to keep. When the project is signed off, delete the app registrations in both tenants; that revokes every permission and certificate at once, and the migrated content and reports are unaffected.
ShareShift handles the SharePoint, OneDrive, Teams and Planner half of a tenant to tenant project on a flat plan with unlimited data, priced per registered worker, and the 30-day trial lets you run the pilot on real content before committing. Plans are on the pricing page.
Frequently asked questions
Can Microsoft migrate SharePoint sites between tenants for free?
Only for Enterprise Agreement customers, using the cross-tenant SharePoint migration PowerShell, licensed per 100 GB moved, one-and-done with no delta passes and no Teams channels. OneDrive accounts can be moved by any customer with the per-user Cross-tenant User Data Migration licence, under the same no-delta constraint.
How long does a tenant to tenant migration take?
Content volume divided by Microsoft's bands: about 10 TB a day for light content, 1 TB a day for medium content, 250 GB a day for heavy content, per tenant, with no SLA. Off-peak scheduling helps because weekday daytime limits are tighter. Incremental passes mean the cutover itself is short even when the bulk pass took weeks.
Do Teams conversations migrate between tenants?
Standard and private channel posts can be imported as native messages with original authors and timestamps through Microsoft's migration mode API. Chats cannot be re-created by any supported API; they are delivered as archives, or moved by Microsoft's Migration Orchestrator with per-user licences.
Do I need identities in the destination before migrating content?
Yes. Content tools map source users to destination users by UPN and verify them at the destination so authorship survives; anyone unresolved falls back to a nominated account and is reported. Create or sync the accounts first.
Run your first migration on a 30-day free trial
Every workload, unlimited data, three workers, pause and resume built in. Worker-only, so your content never passes through our servers. The trial key is issued from the portal and works with the same app you would buy.