Your Complete 2026 Guide to Microsoft 365 Tenant-to-Tenant Migration
A tenant-to-tenant migration moves users, mailboxes, and files from one Microsoft 365 tenant to another, but Microsoft’s documented native cross-tenant tools cover only Exchange Online mailboxes and OneDrive. Teams, Microsoft 365 Groups, and SharePoint need separate planning, and every migrated user needs a Cross-Tenant User Data Migration license or the move fails. It is never one switch. It is a few hundred small decisions, and the ones you skip on day one become the outage on day thirty. Go deeper: Dynamics 365 Commerce for Retail and Omnichannel in 2026.
This guide is written for the CTO, IT director, or VP who owns that outcome. We will cover what a tenant-to-tenant migration really moves, what Microsoft does not move for you, the limits that quietly derail a Microsoft 365 migration, and a phased plan you can adapt. No tool pitch, just the order of operations that keeps your tenant-to-tenant migration from turning into an outage. As a Microsoft partner, Techverx helps teams do exactly this.
What Tenant-to-Tenant Migration Actually Means
A tenant is your organization’s dedicated boundary inside Microsoft’s cloud: identities, mailboxes, files, policies, and licenses. A tenant-to-tenant migration moves users and their data from one boundary to another. The usual triggers are an acquisition, a divestiture, a rebrand, or the clean-up of a multi-tenant estate that grew by accident. Whatever the trigger, the tenant-to-tenant migration has to land without breaking how people work.
Here is the part vendors tend to blur. Directory sync is not migration. Microsoft’s own documentation says cross-tenant synchronization is not a migration tool, because the source tenant is required for synchronized users to authenticate. It creates B2B collaboration users in the target tenant, and moving mail, OneDrive content, and SharePoint data is a separate job. Teams that treat sync as step one of a tenant-to-tenant migration end up with a convincing-looking directory and an empty workspace.
Why a Tenant-to-Tenant Migration Carries Higher Stakes Than the Plan Suggests
Most tenant-to-tenant migration projects ride on top of a business event, such as an acquisition or a divestiture, and that is where the pressure comes from. Several of Microsoft’s rules are also one-way. After a successful mailbox move the source mailbox is deleted and can no longer be discovered in the source tenant, and OneDrive moves are one-shot with no delta passes. When email addresses break, calendars vanish, and files go read-only during the first quarter of integration, the new organization feels it long before any integration benefit shows up on a slide.
That is why we treat every Microsoft 365 tenant-to-tenant migration as a business continuity project first and a technical one second. The technology behind a tenant-to-tenant migration is well documented. The sequencing, communication, and ownership are where projects bleed time.
What Microsoft Moves Natively in a Tenant-to-Tenant Migration (and What It Does Not)
Before you pick a tool or a date for your tenant-to-tenant migration, get clear on the native boundary. Based on the Microsoft Learn articles for cross-tenant mailbox and OneDrive migration (both last updated in May 2026), this is the practical picture today. Microsoft updates this area often, so confirm the current SharePoint and Teams status before you lock a plan.
| Workload | Native cross-tenant support | What to plan around |
| Exchange Online mailboxes | Yes, with the Cross-Tenant User Data Migration license | Mail, calendar, contacts, tasks, and notes move. Holds block the move. Batches stay at 2,000 mailboxes or fewer |
| OneDrive | Yes, same add-on license | Up to 4,000 accounts scheduled at a time, 5 TB or 1 million items per account, 400-character path limit, no delta passes |
| Microsoft 365 Groups | Not supported by mailbox migration or cross-tenant migration of mail | Recreate and move content separately during the Microsoft 365 migration |
| Teams chats and meetings | Chat folder content does not migrate | Meeting URLs become invalid, so meetings must be recreated |
| SharePoint sites and Teams channels | Not covered by the mailbox or OneDrive articles | Usually needs a third-party tool or a managed rebuild |
| Sensitivity labels and signatures | Not migrated (labels are not exported between tenants) | Recreate labels in the target tenant |
Read that table twice. The summary is that a native tenant-to-tenant migration is excellent for mail and OneDrive and silent on much of what makes a modern workplace feel like home. In its cross-tenant mailbox migration article, Microsoft says plainly that cross-tenant migration only migrates mailbox data and nothing else, and points to other options for everything beyond that.
Planning Decisions That Make or Break a Tenant-to-Tenant Migration
Licensing Comes First, and Microsoft Makes No Exceptions
Every migrated user needs a Cross-Tenant User Data Migration license, a one-time fee assignable to either the source or target user object. It covers both mailbox migration and OneDrive migration. Microsoft states that a tenant-to-tenant migration fails without it and that there are no exceptions. Buy it in week one of the tenant-to-tenant migration, not the night before your first batch.
Domains Can Live in Only One Tenant
This single rule shapes your entire tenant-to-tenant migration cutover. A custom domain such as contoso.com can belong to just one tenant, so your target MailUsers cannot carry the old domain until it is removed from the source. The result is a two-stage identity: users first exist on temporary onmicrosoft.com or new-brand addresses, and the domain moves later. Plan the communication around that, because people will see their email address change.
Holds and Compliance Data
Mailboxes and OneDrive accounts under any hold are blocked from any tenant-to-tenant migration. Legal and compliance teams need to be in the room early, because the fix is to lift the hold, migrate, and reapply it in the target tenant. Also note that after a successful mailbox migration, the source mailbox is deleted and can no longer be searched by eDiscovery in the source tenant. If anyone needs that content, copy it first.
Identity and the Source Tenant’s Lifespan
Decide early how users will authenticate during the tenant-to-tenant migration, whether through Entra Connect, cloud-only accounts, or cross-tenant sync for a coexistence period. Sync is useful for coexistence, because it gives people in one tenant B2B access to resources in the other while the cross-tenant migration runs, but remember it manages identities, not content. For hybrid environments, double-check on-premises attributes such as msExchMailboxGUID and proxyAddresses first, or you will create duplicate mailboxes.
Security deserves its own line in the plan. A tenant-to-tenant migration creates short windows where policies differ between tenants, and attackers know it. Our note on why cyber attacks are increasing in 2026 is a useful read before you decide how much dual-tenant overlap you can tolerate.
A Phased Plan for Your Tenant-to-Tenant Migration
Every tenant-to-tenant migration we have seen succeed follows the same five phases, in the same order. Skip one and the cost shows up later, usually at the worst possible moment.
Phase 1: Discovery and Mapping
Inventory everything before your tenant-to-tenant migration touches anything: users, shared mailboxes, distribution lists, Microsoft 365 Groups, Teams, SharePoint sites, Power Platform apps, third-party SSO integrations, and conditional access rules. Build an identity mapping file that pairs each source user with a target user. This file feeds both the mailbox migration and the OneDrive migration, so errors here show up later as failed batches.
Watch delegates closely. Cross-tenant mailbox and calendar permissions are not supported across the boundary, so principals and their delegates travel in the same batch.
Phase 2: Prepare the Target Tenant
Configure the target tenant first in any tenant-to-tenant migration. You will register a migration application, create the organization relationships, and set up a mail-enabled security group in the source that scopes which mailboxes can move. For each user, create a MailUser in the target with the source ExchangeGUID, the ArchiveGUID if one exists, and the source LegacyExchangeDN stamped as an x500 address. Microsoft says the move does not proceed without these, and the x500 address is also what keeps replies to old email threads from bouncing.
One trap deserves a warning label: do not license the target MailUser before the ExchangeGUID is set. Doing so creates a fresh empty mailbox, and you will spend a day untangling it.
Phase 3: Pilot, Then Batch
Start your tenant-to-tenant migration with a pilot of 20 to 50 friendly users across different roles: someone with a giant archive, someone with heavy delegate use, someone who lives in Outlook mobile. Microsoft recommends keeping batches at 2,000 mailboxes or fewer and submitting them about two weeks before cutover, since synchronization does not affect end users while it runs. Use that window. Initial sync takes the pressure off the cutover weekend of your tenant-to-tenant migration.
Over-quota mailboxes fail a mailbox migration, so check sizes before you submit. Reduce them or enable archives first. Up to 12 auxiliary archives are supported, but if the source mailbox expands mid-move, that mailbox migration fails.
Phase 4: Cutover and Day 1 of the Tenant-to-Tenant Migration
Mail flow during a tenant-to-tenant migration behaves like Exchange hybrid. Inbound mail hits the source MailUser first, then forwards to the target mailbox, which means anti-spam and transport rules run in both tenants.
Then comes the part users actually notice. Because the old primary SMTP address is no longer associated with the user in the target tenant, Outlook cannot find the moved mailbox with the old profile. Microsoft’s guidance is that users must rebuild their Outlook profile with the new UPN and primary SMTP address and resync the OST. Across a few thousand people that is a network load problem, so stagger completions by department and give the help desk a script.
Phase 5: OneDrive and Files
In a tenant-to-tenant migration, OneDrive content moves within the Microsoft cloud, with each user’s drive read-only for just a few minutes. The pitfalls are mundane and common: target OneDrive sites that were created before migration (which fail the move), paths longer than 400 characters, apostrophes in usernames, and accounts over 5 TB or 1 million items. There are no incremental passes, so each OneDrive migration is one shot. Check path lengths in advance and ask users to flatten deeply nested folders.
If your team would rather not carry this planning alone, Techverx offers Microsoft 365 consulting for US and Canadian enterprises, including tenant-to-tenant migration planning and post-move support.
The Teams and SharePoint Gap in Tenant-to-Tenant Migration
Ask project sponsors what staff care about and the answer is not mailboxes. It is the Teams channel where the work happens and the SharePoint library with eleven years of proposals. This is exactly where a native tenant-to-tenant migration thins out. Teams chat folder content does not move, meeting URLs break, and Microsoft 365 Groups need their own approach.
Two Ways to Close the Gap
- Third-party migration platform. Tools built for Teams and SharePoint can map channels, preserve permissions, and run incremental passes. It is the faster route for a large Microsoft 365 migration, at the cost of licensing and a vendor to manage.
- Managed rebuild. For smaller or cleaner environments, recreate team structures in the target tenant and move content in curated waves. It is slower, but it forces a clean-up and you migrate far less dead weight.
A good rule: if your SharePoint estate has heavy custom workflows, term sets, or retention labels, budget for a specialist tool. If it is mostly document libraries, a curated move often wins on cost and cleanliness.
The 2,000 and 4,000 numbers to remember
Microsoft limits mailbox batches to 2,000 mailboxes and OneDrive scheduling to 4,000 accounts at a time. Spread your waves around those limits and the cutover calendar of your tenant-to-tenant migration mostly writes itself.
How Long a Tenant-to-Tenant Migration Takes and What Drives the Cost
Small organizations can finish a tenant-to-tenant migration in a few weeks. Enterprises with thousands of users, regulated data, and a deep SharePoint estate more often plan for several months. The calendar is driven less by data volume than by dependencies: domain release, legal holds, and hand-mapping Teams and sites.
On cost, a tenant-to-tenant migration comes down to three lines. The per-user Cross-Tenant User Data Migration license, any third-party tool for Teams and SharePoint, and the labor to prepare MailUsers, run batches, and support users through the Outlook profile rebuild. Teams that underbudget a Microsoft 365 tenant-to-tenant migration almost always underbudget the third line. Related reading: Is Microsoft 365 Copilot Worth the Cost for Small Businesses.
Tenant-to-Tenant Migration Mistakes That Turn a Clean Plan Into a Long Weekend
- Treating cross-tenant sync as migration. It manages identities and never moves content.
- Skipping the licensing check. No Cross-Tenant User Data Migration license, no move.
- Ignoring holds. Legal holds block the move and surface late, usually on cutover day.
- Leaving Outlook as an afterthought. The profile rebuild is the single biggest source of Day 1 tickets.
- Forgetting Teams meetings. Meeting URLs are not updated during the move, so organizers must remove and recreate recurring meetings or invitees keep clicking dead links.
- Decommissioning the source tenant too early. OneDrive redirects persist until the source tenant is deprovisioned, so shared links depend on it.
Most failed tenant-to-tenant migration projects fail for non-technical reasons. They are ownership failures: nobody was assigned to Teams meetings, or to legal holds, or to the help desk script. Name an owner for every workload in your tenant-to-tenant migration plan, from mailbox migration to OneDrive migration to the help desk.
After the Tenant-to-Tenant Migration: Security, Copilot, and Clean-Up
Once users are live after the tenant-to-tenant migration, resist the urge to declare victory. Recreate sensitivity labels, restamp Send on Behalf permissions, rebuild transport rules, and audit conditional access so the new tenant is at least as strict as the old one. Then keep the source tenant in a read-only holding pattern for a set period before you shut it down.
This is also the right moment to think about what the new tenant is for. Many organizations consolidate so they can roll out AI tooling across one clean environment. If Copilot is on your roadmap, our comparison of Microsoft 365 Copilot and ChatGPT will help you decide where it fits once your data lives in one place.
Bringing It Together
A tenant-to-tenant migration is rarely about technology alone. It is about sequencing: licenses before batches, domains before cutover, holds before moves, and people before tools. Microsoft’s native tooling handles tenant-to-tenant migration of mailboxes and OneDrive well, but Teams, SharePoint, and Groups usually need extra planning or a specialist platform.
Start your tenant-to-tenant migration with a thorough inventory, pilot early, use the two-week sync window, and give every workload a named owner. Do that, and your cutover weekend stays a quiet one.
