What Is
Tenant-to-Tenant Migration?
A plain-English guide to what tenant-to-tenant migration is, when businesses need it, and how the process actually works.
Tenant-to-tenant migration is one of the most commonly searched but least clearly explained concepts in Microsoft 365. The term sounds technical but the underlying situation is straightforward: two separate Microsoft 365 environments that need to become one — or one that needs to become two. This guide explains what tenant-to-tenant migration is, when businesses need it, and what the process actually involves.
What is a Microsoft 365 tenant?
Before explaining tenant-to-tenant migration, it helps to understand what a tenant is. A Microsoft 365 tenant is your organisation's dedicated instance of Microsoft 365 — your own private environment containing all your users, email, SharePoint sites, Teams, and OneDrive storage. Every organisation using Microsoft 365 has its own tenant, identified by a unique onmicrosoft.com address (like yourcompany.onmicrosoft.com) even if they use a custom domain for email.
What is tenant-to-tenant migration?
Tenant-to-tenant migration is the process of moving data — mailboxes, SharePoint sites, OneDrive files, Teams channels — from one Microsoft 365 tenant to another. Unlike a migration from an on-premise server or a different email platform, both the source and the destination are already Microsoft 365 environments. The challenge is that Microsoft 365 does not natively provide tools to move data between tenants — it requires specialist tooling and careful sequencing.
When do businesses need tenant-to-tenant migration?
Mergers and acquisitions. The most common scenario. Company A acquires Company B. Both have their own Microsoft 365 tenants. The combined organisation wants a single unified environment. Tenant-to-tenant migration consolidates Company B's users and data into Company A's tenant.
Divestitures and spin-offs. The reverse scenario — a business unit or subsidiary is separated from a parent company. Users and data from one tenant need to move to a new, independent tenant for the newly separated organisation.
Rebranding with domain changes. A business that changes its name and domain may need to establish a new tenant rather than renaming the existing one, requiring data to move across.
Consolidation after previous acquisitions. Organisations that have grown through multiple acquisitions over time often operate several Microsoft 365 tenants. Consolidating these into a single tenant reduces administrative overhead and licensing complexity.
What moves in a tenant-to-tenant migration?
A tenant-to-tenant migration can include:
- Exchange Online mailboxes (email, calendar, contacts)
- SharePoint Online sites and document libraries
- OneDrive for Business personal storage
- Microsoft Teams channels and associated files
- Distribution lists, shared mailboxes, and resource rooms
- Security groups and Azure AD objects
Not everything migrates perfectly. Some Teams data — private chat history in particular — has limitations in cross-tenant migration due to Microsoft's architecture. A migration plan should clearly document what will and will not migrate.
The main challenges of tenant-to-tenant migration
Identity mapping. Every user, group, and permission in the source tenant must be mapped to an equivalent in the destination tenant. A user in Tenant A needs to become the correct corresponding user in Tenant B — with all their permissions and group memberships correctly translated. Errors in identity mapping break access to migrated content.
Email continuity during migration. During a phased migration, some users are in the source tenant and some are in the destination. Email between them must continue to flow correctly. This requires cross-tenant mail routing configuration that keeps both populations able to communicate throughout the migration period.
SharePoint and Teams dependencies. Teams channels depend on SharePoint — each Team has an underlying SharePoint site. Moving Teams data requires understanding and preserving these dependencies across tenant boundaries.
Batching and sequencing. Large organisations cannot move every user simultaneously. The migration must be planned in batches — typically by department or business unit — with each batch planned and validated before the next begins.
How long does tenant-to-tenant migration take?
Tenant-to-tenant migrations are typically the longest type of Microsoft 365 migration project. A realistic timeline:
| Organisation size | Typical timeline |
|---|---|
| Under 100 users | 4–8 weeks |
| 100–500 users | 8–16 weeks |
| 500+ users | 4–9 months |
The identity mapping phase — before any data moves — is the part that cannot be rushed. A complete and accurate identity map is the foundation that everything else depends on.
How is tenant-to-tenant migration different from other Microsoft 365 migrations?
The key difference is that both environments are already Microsoft 365. This removes some challenges (no platform conversion, no format changes) but creates others (Microsoft does not natively support tenant-to-tenant data movement, cross-tenant identity is complex, and the risk profile is different when both environments are live throughout the migration).
CloudyNex's tenant-to-tenant migration service is built specifically to handle identity mapping, batching, and coexistence mail routing for mergers, acquisitions, and divestitures. For businesses weighing up their options before committing, our migration consulting service can assess the complexity of your specific situation.
Frequently asked questions
Related articles
Need help with
your migration?
Request a free consultation.
No commitment required · Response within one business day · sales@cloudynex.co