Moving Between Microsoft 365 Tenants: What Businesses Need to Plan
A Microsoft 365 tenant-to-tenant migration moves supported email, OneDrive, SharePoint and selected Teams data between separate organisations. It does not automatically move identities, domains, devices, applications, policies or every Teams feature, so each workload must be discovered, designed, migrated and validated separately.
A company acquires another business. Both organisations already use Microsoft 365. The initial assumption is: they are both Microsoft 365, so this should be straightforward.
The acquired business has its own Microsoft tenant, its own email domain, Exchange mailboxes, OneDrive accounts, SharePoint sites, Microsoft Teams, guest users, mobile devices, application registrations, security policies, retention rules, backups and supplier access.
The acquiring company wants everything moved into its main tenant. The project then discovers that users need new target identities, the domain cannot remain attached to both tenants simultaneously, Entra object IDs change, applications trust the old identities, sharing links may change, Teams structure needs separate handling, SharePoint sites may not merge into existing sites, some mailboxes are on hold, Conditional Access differs, devices remain joined to the source tenant, external users exist in both environments, backup and retention must continue throughout, and the old tenant cannot be cancelled the moment migration completes.
Two businesses may both use Microsoft 365 while still operating in completely separate identity, security and data environments.
The Quick Answer
A Microsoft 365 tenant-to-tenant migration can move supported email, OneDrive, SharePoint and selected Teams data between separate Microsoft 365 organisations.
However, the project must also address:
- Target identities — new user objects in the destination tenant
- Domain ownership — a domain cannot remain attached to two tenants
- Licences — migration and destination licences for each user
- Mail routing — DNS, MX, SPF, DKIM and DMARC
- Permissions — mailbox delegates, sharing and group membership
- Applications — SSO, OAuth, app registrations and service principals
- Devices — re-enrolment, Intune, Autopilot and Defender
- Teams structure — channels, chats and meetings follow different paths
- Security policies — Conditional Access, sensitivity labels and data-loss prevention
- Retention and legal holds — some mailboxes may be blocked from migration
- Backup — migration does not replace backup
- User communications — sign-in names, Outlook profiles and device changes
- Source-tenant closure — only after contractual, operational and recovery checks
Microsoft now provides more native migration capability than it did several years ago, including coordinated migration through Migration Orchestrator. However, no single tool automatically combines every Microsoft 365 workload and configuration.
Do not remove the source domain, cancel licences or delete source accounts until the migration sequence and recovery position are proven.
Last checked: 4 August 2026. Microsoft's migration tooling, licensing eligibility and supported workloads should be verified in current Microsoft documentation before project approval.
What is a Microsoft 365 tenant?
A Microsoft 365 tenant is a separate Microsoft cloud organisation. It has its own identity directory in Microsoft Entra ID, its own domains, its own Exchange Online environment, its own SharePoint, OneDrive and Teams services, its own licences, its own security policies and its own administrative boundary.
A Microsoft 365 tenant migration moves selected data between two separate organisations. It does not combine every identity, configuration and service automatically.
The data can move while the identity, permissions, applications and security configuration still need rebuilding.
Why businesses need tenant-to-tenant migration
Tenant-to-tenant migrations are usually driven by structural business events rather than technology preferences.
| Scenario | What it requires |
|---|---|
| Merger or acquisition | Two organisations consolidate into one Microsoft environment. |
| Divestiture | A business unit or trading entity must leave the parent tenant. |
| Company separation | Trading divisions become legally or operationally independent. |
| Group consolidation | Several subsidiaries move into one centrally managed tenant. |
| Tenant ownership problem | The business operates in a tenant controlled by a former supplier, parent company or previous owner. |
| Geographic restructuring | Users and data move into another regional operating model. |
| Security standardisation | The organisation wants one identity and security framework. |
| Licensing consolidation | Separate purchasing arrangements are combined where commercially appropriate. |
| Brand or domain change | A restructuring requires a new primary domain or tenant identity. |
| Compliance separation | Data and administration must be separated for regulatory or contractual reasons. |
The correct architecture may be consolidation, coexistence or separation — not automatically migration into the largest tenant.
Can Microsoft 365 tenants be merged?
Microsoft 365 does not offer a simple command that combines every user, configuration, workload and policy from two tenants. A tenant consolidation normally requires creating or matching target identities, migrating supported data, moving or changing domains, recreating groups, rebuilding policies, reviewing permissions, reconfiguring applications, re-enrolling devices, communicating with users and retaining the source tenant temporarily.
A tenant merger is a programme of connected migrations and configuration changes — not one Microsoft merge operation.
What Microsoft's native tools can currently move
Microsoft currently supports native cross-tenant migration for several workloads. Availability depends on the workload, licence and customer agreement. Some capabilities remain in preview.
| Workload | Current native support | Notes |
|---|---|---|
| Exchange Online mailboxes | Supported — cross-tenant mailbox migration | Requires Cross-Tenant User Data Migration licence. Certain hold conditions may affect eligibility. |
| Archive mailboxes | Supported for eligible scenarios | Verify current requirements and limitations. |
| OneDrive | Supported — cross-tenant user data migration | Requires Cross-Tenant User Data Migration licence per user. Identity mapping required. |
| SharePoint sites | Supported — cross-tenant site migration | Requires separate per-user or data-volume licensing. Target site must not already exist. Verify current limits. |
| Teams chats | Available via Migration Orchestrator — verify current status | Migration Orchestrator may include selected chat and meeting content. Verify preview or GA status. |
| Teams meetings | Available via Migration Orchestrator — verify current status | Meeting data may depend on mailbox and chat migration status. |
| Teams channels | Not moved by SharePoint site migration alone | Channel structure and messages may require separate tooling or recreation. |
| Teams files | Follow SharePoint and OneDrive workload rules | Files in Teams reside in SharePoint or OneDrive. |
| Teams apps, tabs, Planner | Not automatically migrated | Require recreation or separate tooling. |
| Identities, passwords, MFA | Not automatically moved | Target user objects must be created and configured separately. |
| Devices, Intune, Autopilot | Not automatically moved | Device re-enrolment and Autopilot transfer require separate planning. |
| Application registrations | Not automatically moved | App registrations, enterprise applications and service principals must be recreated in the target. |
| Conditional Access, sensitivity labels | Not automatically moved | Security and compliance configuration must be rebuilt in the target. |
Current limits for site sizes, item counts, batch sizes, incremental capabilities and supported plan eligibility should be checked immediately before project approval. Third-party tooling may still be appropriate for unsupported or complex workloads.
Migration Orchestrator
Microsoft currently describes Migration Orchestrator as a coordinated tenant-to-tenant migration service. Microsoft currently describes its supported workloads as including Exchange Online mailboxes, OneDrive, Teams chats and Teams meetings. Availability depends on the workload, licence and purchasing channel.
Migration Orchestrator moves supported user content. It does not automatically move or recreate every identity, device, policy, application or organisation-wide configuration.
Some Migration Orchestrator capabilities remain in preview. Verify current availability, general-availability status, supported Microsoft 365 plans, licence requirements and supported Teams content before planning.
What does not move automatically
Migrating content does not recreate the complete operating environment around it.
| Item | Why it needs separate handling |
|---|---|
| Entra object IDs | Each tenant has its own identity objects. Source IDs do not transfer. |
| Passwords and authentication methods | MFA registration must be completed in the target tenant. |
| Conditional Access policies | Must be created or ported to the target. |
| Administrative roles | Target admins must be assigned roles separately. |
| Licence assignments | Licences must be assigned in the target tenant. |
| Enterprise applications | Applications trust source-tenant service principals; target registration required. |
| App registrations and service principals | Must be recreated with new secrets and certificates. |
| Device registrations and Intune enrolment | Devices remain joined to the source; re-enrolment needed. |
| Autopilot profiles | Autopilot registration must be transferred to the target tenant. |
| Defender configuration | Security policies must be configured in the target. |
| Microsoft 365 groups and dynamic-group rules | Groups must be recreated in the target. |
| Distribution lists and mail-enabled groups | Must be created in the target Exchange environment. |
| Guest-user relationships | Guests are linked to the source tenant; re-invitation may be required. |
| Teams apps, tabs and Planner plans | Not covered by content migration; require separate handling. |
| Power Automate flows, Power Apps, Forms | Attached to source-tenant identities; must be rebuilt. |
| Stream content | Verify current storage location and migration path. |
| Sensitivity-label configuration | Labels must be created and published in the target. |
| Retention policies and legal holds | Must be configured in the target Microsoft Purview environment. |
| eDiscovery cases and audit history | Audit history is tenant-specific and does not migrate. |
| Backup configuration | Target backup must be configured and tested separately. |
| DNS, SPF, DKIM, DMARC | Must be updated in the target domain configuration. |
| Outlook profiles | Users will need new Outlook profiles in the target tenant. |
| Mobile-device profiles | Mobile devices need reconfiguration for the new tenant. |
Items not supported by native tooling may require export and import, recreation, remapping, specialist tooling, manual configuration, continued source access or retirement.
Identity mapping and new user objects
Identity mapping is central to every workload. A source user may have a source Entra object ID, a source user principal name, a source Exchange GUID, source OneDrive content, source Teams identity, source group memberships and source application access. The target user will normally have a separate identity created in the target tenant.
Migration tools must match the correct source and target objects. Incorrect mapping can cause data assigned to the wrong user, missing permissions, broken mailbox moves, inaccessible OneDrive content, duplicate accounts, failed Teams migration or broken application access.
The migration moves data to a target identity. It does not carry the original identity object into the new tenant unchanged.
Microsoft currently provides Cross-Tenant Identity Mapping capability as part of the migration toolkit. Verify whether this remains preview or is generally available at the time of project planning.
Moving a custom domain
A verified custom domain cannot remain actively attached to two Microsoft 365 tenants simultaneously. Moving a domain requires identifying every source object using the domain, changing source user principal names, removing or replacing aliases, updating groups and contacts, removing application references, confirming no source dependencies remain, removing the domain from the source tenant, adding and verifying it in the target tenant, assigning target user names and email addresses, and updating DNS and mail routing.
Potential issues during domain migration include user sign-in changes, Teams SIP addresses, email aliases, applications using the old user principal name, mobile profiles, Outlook profiles, external sharing, cached credentials, certificates, website forms, scanners, SaaS applications and DNS propagation delays.
The domain cutover is often the most visible moment of the project, but the dependency cleanup must happen before it.
Exchange Online mailbox migration
Microsoft currently supports native cross-tenant Exchange mailbox migration for qualifying environments. The migration can move active mailbox content including email, contacts, calendars, tasks and notes for supported mailbox types.
| Mailbox type | Consideration |
|---|---|
| Active user mailboxes | Main supported workload for cross-tenant mailbox migration. |
| Archive mailboxes | Supported for eligible scenarios — verify current requirements. |
| Shared mailboxes | Verify current cross-tenant support and prerequisites. |
| Resource mailboxes | Rooms and equipment mailboxes require separate planning. |
| Mailboxes on litigation hold | May require legal review; certain hold conditions may affect native migration eligibility. |
| Mailboxes on retention hold | Retention settings must be assessed before migration. |
| Inactive mailboxes | Require separate handling; verify current options. |
| Public folders | Not moved by cross-tenant mailbox migration; require separate handling. |
| Delegates and send-as rights | Mailbox permissions do not automatically transfer; must be rebuilt. |
| Inbox rules | May not transfer automatically; verify current behaviour. |
| Distribution lists | Must be created in the target Exchange environment. |
| Transport rules and connectors | Must be configured in the target tenant. |
| Third-party email security gateways | Configuration must be updated for the target domain and routing. |
A mailbox move can preserve messages while still requiring permissions, groups, connectors and mail flow to be rebuilt.
After a successful native cross-tenant mailbox move, source-mailbox behaviour may differ from a copy-based migration — the source mailbox is not an independent duplicate. Verify the current Microsoft process for source-mailbox handling after completion.
X500 addresses and reply continuity
Historic messages may contain internal Exchange addressing references. Preserving suitable X500 legacy addresses on target mailboxes can help avoid non-delivery when users reply to old emails, use cached Outlook address suggestions, respond to old meeting invitations or reference migrated contacts. This is a frequently overlooked step in mailbox migration planning.
Mailbox holds and compliance
Mailboxes subject to litigation hold, retention hold, eDiscovery hold, regulatory preservation or inactive-mailbox requirements may require legal review, a different migration route, hold removal where authorised and documented, export, source retention, or compliance redesign in the target.
A technical migration deadline does not override a legal preservation duty.
OneDrive migration
Microsoft currently provides native cross-tenant OneDrive migration for supported scenarios. A OneDrive migration must consider target-user creation, target OneDrive provisioning, storage capacity, file limits, invalid characters in file or path names, path lengths, version history, sharing arrangements, external users, OneDrive shortcuts, known-folder redirection, sync-client configuration, local files, redirects, source-account behaviour and retention settings.
After migration, users may need new OneDrive sign-in, sync-client reconfiguration, Known Folder Move reassignment, access-link updates and local cache cleanup.
The files can move in Microsoft's cloud while every user device still needs to follow them to the new tenant.
Departed users may have OneDrive content that requires separate assessment. Encryption configurations using sensitivity labels or Microsoft Purview Customer Key may affect migration eligibility. Verify current limits and restrictions before planning.
SharePoint migration
Microsoft provides native cross-tenant SharePoint site migration for supported customers. SharePoint migration is a site-level project, not a file copy.
- An existing target site cannot be overwritten or merged — the target URL must be a new site
- Site and item count limits apply — verify current maximums before planning
- Migration may be one-time rather than incremental — verify current capabilities
- Sites using sensitivity labels with Microsoft Purview Customer Key may be ineligible
- Source and target configuration must meet prerequisites before migration begins
- Teams-connected SharePoint site migration moves the SharePoint content but does not itself migrate the Teams channel structure
- Hub sites, navigation and custom web parts may need separate handling
- Power Automate flows, Power Apps and forms attached to sites must be rebuilt in the target
Moving a SharePoint site is not the same as merging its contents into an existing target department site.
A SharePoint site inventory should include site type, storage, item count, permissions, external sharing, Microsoft 365 group connections, Teams connections, hub-site relationships, custom components and retention settings before any migration is planned.
Microsoft Teams migration
"Teams migration" can describe several different workloads that do not all move through the same process.
| Teams component | Current migration position |
|---|---|
| Teams identity and membership | Users and groups must exist or be mapped in the target before Teams content can be assigned. |
| Private chats | May be supported through Migration Orchestrator — verify current preview or GA status. |
| Group chats | Verify current support via Migration Orchestrator. |
| Meeting information | May depend on mailbox and chat migration being completed first. |
| Channels and channel messages | Channel structure and messages may require separate tooling or recreation — not moved by SharePoint site migration alone. |
| Teams files | Files reside in SharePoint or OneDrive and follow those workload migration rules. |
| Meeting recordings | Reside in OneDrive or SharePoint — follow the relevant workload rules. |
| Teams apps and tabs | Must be reinstalled and reconfigured in the target. |
| Planner plans | Must be recreated in the target. |
| Teams Phone — numbers, queues, auto attendants | Voice configuration requires separate planning; not moved by content migration. |
| Private channels | Private-channel SharePoint sites require separate assessment. |
| Shared channels | Shared channels involve external identity; verify current cross-tenant behaviour. |
Teams support is not identical to SharePoint support and native migration does not move every Microsoft 365 Teams setting. Verify current Teams migration capabilities before project approval.
Applications, automation and single sign-on
Applications may trust the source tenant through Microsoft Entra SSO, OAuth, SAML, OpenID Connect, app registrations, enterprise applications, service principals, certificates, secrets, API permissions, user assignments, group assignments, Conditional Access policies, managed identities and provisioning.
Business applications commonly integrated with Microsoft 365 include finance software, CRM, HR systems, backup platforms, cyber-security tools, document management, websites, line-of-business applications, automation, reporting and supplier portals. Each integration may require a target app registration, new secret or certificate, updated redirect URI, new consent grant, user reassignment, vendor involvement, testing and source decommissioning.
A user may receive their email in the target tenant while still depending on the source identity to operate a business application.
Power Automate flows, Power Apps and Microsoft Forms are attached to source-tenant identities and will not migrate automatically. Each automation that the business depends on requires a rebuild in the target tenant.
Devices, Intune and Defender
User devices may be Entra joined, hybrid joined, Entra registered, Intune enrolled, Autopilot registered, managed by Defender, configured by group policy, protected by Conditional Access, using Windows Hello for Business, using certificates, using VPN profiles or using compliance policies.
A tenant migration may require device profile migration, device reset and re-enrolment, Autopilot transfer, new compliance policy, new certificates, application reinstallation, BitLocker-key handling, OneDrive reassignment, Outlook reconfiguration, MFA registration and user communication.
The user moves between tenants logically. The device still needs to trust and register with the new organisation.
Security and compliance
The target tenant should be secured before data and users arrive. Cross-tenant access settings in Microsoft Entra can affect B2B collaboration, MFA-claims trust, compliant-device claims, hybrid-joined-device claims and inbound and outbound access. These settings can support coexistence during migration but do not replace the need to build a properly secured target environment.
| Security area | What must be configured in the target |
|---|---|
| Administrator accounts | Cloud-only Global Administrator accounts with emergency access. |
| MFA | Required for all users before data arrives. |
| Conditional Access | Policies must be designed and implemented for the target. |
| Privileged roles | Privileged Identity Management where licensed; roles assigned deliberately. |
| External collaboration | Cross-tenant access settings, guest access and tenant restrictions reviewed. |
| Microsoft Defender | Defender for Microsoft 365 configured and monitoring. |
| Intune | Device compliance and application policies ready before re-enrolment. |
| Audit logging | Enabled and confirmed in the target tenant. |
| Sensitivity labels | Labels created and published in the target Microsoft Purview environment. |
| Retention policies | Configured in the target before user data arrives. |
| Data-loss prevention | DLP policies configured for the target. |
| Backup | Target Microsoft 365 backup configured and tested. |
| Domain security | SPF, DKIM and DMARC configured for the target domain. |
Do not weaken the target tenant to make migration easier and then forget to restore the controls.
Discovery and target design
A tenant-migration estimate prepared from user count alone is mostly a guess. Discovery must cover every workload before a migration plan is produced.
| Discovery area | What to assess |
|---|---|
| Business | Reason for migration, legal entities, transaction dates, separation agreements, deadlines, blackout periods, executive sponsor. |
| Tenants | Source and target ownership, administrator access, purchasing model, licence agreements, regions, Multi-Geo requirements. |
| Identities | Active users, former users, guests, service accounts, privileged accounts, groups, aliases, domains, authentication methods. |
| Exchange | Mailbox count and sizes, archives, shared mailboxes, public folders, permissions, connectors, transport rules, retention and holds. |
| OneDrive | Account count, storage, external sharing, departed-user data, sync status. |
| SharePoint | Site count, site types, storage, item counts, permissions, customisation, Teams connections, Power Platform usage, sensitivity labels. |
| Teams | Teams, channels, private and shared channels, chats, meetings, recordings, voice, applications, external users. |
| Applications | Enterprise applications, app registrations, secrets, certificates, SSO, provisioning, APIs, automation. |
| Devices | Windows, macOS, mobile, Intune, Autopilot, Defender, certificates, VPN, user profiles. |
| Compliance | Retention policies, legal holds, eDiscovery cases, audit requirements, sensitivity labels, DLP, backup, data residency. |
The target tenant should represent the future operating model — not simply absorb the source tenant's historical clutter. Target design decisions include naming standards, primary domains, user principal names, email addresses, licence strategy, administrative model, group structure, Teams structure, SharePoint architecture, external collaboration, device management, application ownership, security controls, retention, backup, support responsibility and source-retention period.
Before migration, review former users, obsolete mailboxes, unused groups, old guest users, abandoned Teams, stale SharePoint sites, personal OneDrive data, excessive permissions, anonymous links, expired applications, old app secrets and unsupported devices. Do not delete data or access without business ownership, legal approval where required, retention review and a documented decision.
Migration is an opportunity to reduce clutter, but it is not authority to destroy records.
Pilot migration and coexistence
A pilot migration should include representative users from senior management, finance, operations, remote workers, large mailboxes, archive users, heavy OneDrive users, SharePoint owners, Teams users, mobile users, users of specialist applications, users with delegates and users subject to compliance controls.
The pilot should test sign-in, MFA, email, historical mailbox data, calendar, Outlook, OneDrive, SharePoint, Teams, external sharing, mobile access, applications, printing, scanning, devices, backup and the support process.
The pilot is where the project proves its assumptions wrong while the blast radius is still small.
During a staged migration, both tenants may remain active. Coexistence may require cross-tenant access settings, guest accounts, mail routing, address-book planning, calendar sharing, Teams federation, a domain strategy, application access for two identities, licence overlap and clear user instructions. Coexistence reduces the size of a single cutover but increases the time spent operating two separate organisations.
Domain and mail cutover
The domain cutover is a deadline inside the migration — not the whole migration.
| Stage | Key actions |
|---|---|
| Before cutover | Complete discovery, confirm identity mapping, confirm licences, secure target accounts, complete migration passes, test applications, document DNS, prepare support, notify users, confirm rollback options, freeze critical changes. |
| During cutover | Complete final migration activity, remove domain dependencies, move the custom domain, update MX, update SPF, enable or update DKIM, confirm DMARC, change sign-in names, test mail flow, test applications, update user devices, monitor service health. |
| After cutover | Validate mail, calendars, OneDrive, SharePoint, Teams, external sharing, applications; check backup; resolve failed items; communicate status; maintain source access. |
User communications and support
A migration can be technically successful and still feel like failure when users do not know which identity or system to use.
| Phase | What users need to know |
|---|---|
| Before the project | Why the organisation is moving, what will change, expected dates, expected disruption, new sign-in details, training available and support routes. |
| Before cutover | MFA instructions, password or sign-in guidance, Outlook guidance, OneDrive guidance, Teams guidance, mobile instructions, known limitations and support contact. |
| During cutover | Status updates, known issues, priority support and workarounds. |
| After cutover | Confirmation of completion, source-access rules, file-location guidance, common fixes, follow-up training and how to report issues. |
Backup, validation and decommissioning
Migration tools do not replace backup. A migration can transfer a deletion, corruption or permission mistake just as efficiently as it transfers good data.
Before migration: confirm source Microsoft 365 backup covering mailboxes, OneDrive, SharePoint and Teams-related content; confirm departed-user handling; confirm backup administrator access; and test a recent restore.
After migration: confirm target backup coverage; confirm successful authentication; verify new users are protected; verify new SharePoint sites and Teams-related content are covered; run a restore test; and review retention and source-backup retention.
The source tenant may need to remain for legal records, rollback, archive access, unresolved applications, guest relationships, historic audit information, backup, contractual transition or phased separation. Confirm all planned users are migrated, domains are moved, mail flow is stable, OneDrive and SharePoint are validated, Teams requirements are addressed, applications are transferred, devices are moved, compliance records are preserved, legal holds are addressed, licences are reviewed, supplier access is removed and written business approval is obtained before proceeding with decommissioning.
Cutover completes the move into the target. Decommissioning closes the risks left behind in the source.
Common migration mistakes
- Treating the project as email only — ignoring OneDrive, SharePoint, Teams, devices and applications
- Assuming both Microsoft tenants work the same way — each is a separate identity and security boundary
- Using outdated guidance as a current runbook — Microsoft's tooling and procedures change regularly
- Choosing a tool before completing discovery
- No confirmed access to both tenants before the project begins
- No confirmed tenant ownership
- Failing to verify native-tool eligibility for the specific licence and purchasing channel
- Discovering licence restrictions too late in the project
- Not mapping source and target identities before migration begins
- Moving the domain without removing all dependencies first
- Ignoring mailbox holds — migrating without legal review
- Assuming Teams channels follow a SharePoint site migration
- Attempting to merge SharePoint content into an existing target site
- Overlooking application registrations and service principals
- Overlooking service accounts used by applications or automation
- Forgetting devices — assuming mailbox migration equals device migration
- Forgetting Autopilot — Autopilot registration remains in the source tenant
- Forgetting Intune — device compliance policies are tenant-specific
- No pilot migration completed
- No coexistence plan for the transition period
- No user communication before cutover
- No Microsoft 365 backup before or during migration
- No rollback or containment plan
- Cancelling source licences too early — before validation completes
- Retaining the source tenant indefinitely without reviewing ownership and cost
- Copying poor permissions rather than designing the target correctly
- Failing to validate external sharing and guest access in the target
Is your business ready for a Microsoft 365 tenant migration?
Use this readiness checklist before approving a migration plan.
| Area | Questions to confirm |
|---|---|
| Business | Is the reason for migration clear? Is there an executive sponsor? Are legal and transaction dates known? Are separation obligations documented? |
| Ownership | Do we control both tenants? Do we have Global Administrator access? Do we control the domains and DNS? Are supplier responsibilities documented? |
| Identities | Are users and groups inventoried? Are source and target identities mapped? Are administrators identified? Are guests and service accounts included? |
| Are mailbox sizes known? Are archives known? Are permissions documented? Are holds and retention reviewed? Are connectors and transport rules known? | |
| Files | Are OneDrive accounts assessed? Are SharePoint sites assessed? Are sharing and permissions mapped? Are target sites designed? Are unsupported configurations identified? |
| Teams | Are Teams and channels inventoried? Are chats and meetings assessed? Are files and recordings located? Are apps, tabs and voice services recorded? |
| Applications | Are app registrations inventoried? Are enterprise applications inventoried? Are SSO and provisioning dependencies known? Are secrets and certificates scheduled for replacement? |
| Devices | Are Intune devices known? Is Autopilot ownership known? Are certificates and VPN profiles documented? Is re-enrolment planned? |
| Security | Is target MFA configured? Is Conditional Access ready? Are administrative roles controlled? Are external-sharing rules agreed? Is backup configured? |
| Delivery | Has a pilot completed? Is coexistence planned? Is domain cutover documented? Is user support available? Is rollback understood? |
| Closure | Are failed items resolved? Is target backup verified? Are compliance records preserved? Is source closure subject to written approval? |
Warning signs — when to pause
- Either tenant is not under business control
- Global Administrator access is unavailable for source or target
- Domain or DNS access is missing
- Migration licences have not been confirmed for the specific purchasing channel
- Native-feature eligibility is unclear
- Mailbox holds have not been reviewed by a legal or compliance authority
- Source and target identities are not mapped
- Applications have not been inventoried
- Devices are ignored
- Teams is treated as one workload
- SharePoint sites are expected to merge automatically into existing sites
- Users have not been selected for a pilot
- No Microsoft 365 backup exists for source or target
- No rollback or containment plan exists
- The source domain move is scheduled before dependency cleanup is complete
- The transaction deadline is the only project plan
- Source cancellation is booked before validation
- Nobody owns unresolved source data
When the identities, applications and compliance position are unclear, the next phase is discovery — not migration.
Practical business implications
| Implication | What it means in practice |
|---|---|
| Microsoft now provides more native capability | Some organisations may no longer require third-party tools for every workload — but eligibility, licensing and workload scope must be verified. |
| Native does not mean simple | Licensing, purchasing-channel eligibility, identity mapping, workload limitations and PowerShell configuration remain. |
| Tenants do not simply merge | The project combines several migration and reconfiguration activities across multiple workloads. |
| Identities change | Source and target Entra objects remain distinct; applications must be updated. |
| The domain move needs careful timing | Dependencies must be removed before transfer; domain change affects sign-in, mail, Teams and applications. |
| Teams is not one data store | Chats, meetings, channels, files and applications follow different migration paths. |
| SharePoint needs target design | Existing target sites cannot be migration destinations; new site structures must be planned. |
| Devices require their own project | Intune and Autopilot do not move because mailboxes do. |
| Compliance can block or alter the migration | Holds and retention require specialist review before migration decisions are made. |
| Licence overlap is normal | Both tenants may need to operate during transition and validation. |
| Source closure is a controlled stage | It should not happen automatically after cutover; written approval should be required. |
The IT Club view
A Microsoft 365 tenant-to-tenant migration often looks easier than a move from Google Workspace or another platform. Both sides use Outlook, Exchange Online, OneDrive, SharePoint, Teams and Entra ID. The familiar interface can hide the real complexity.
Each tenant is a separate security and identity boundary. The applications may look familiar, but the users, permissions, policies and trust relationships belong to different organisations.
IT Club recommends: verifying current Microsoft guidance before planning; completing discovery before accepting a quote; confirming control of both tenants; verifying migration licensing for the specific purchasing channel; mapping identities deliberately; assessing each workload separately; securing the target before cutover; running a pilot migration; completing application and device discovery; planning the domain transition carefully; communicating with users; confirming backup covers both tenants; retaining the source; and obtaining written approval for decommissioning.
A good tenant migration does not merely move Microsoft 365 data. It creates a target environment the business can own, secure, support and explain.
Related Business Questions
| Question | Answer |
|---|---|
| What is a Microsoft 365 tenant? | A separate Microsoft cloud organisation containing identities, domains, Exchange Online, SharePoint, OneDrive, Teams, licences and security policies. |
| What is tenant-to-tenant migration? | Moving supported data or workloads from one Microsoft 365 tenant into another. |
| Can two Microsoft 365 tenants be merged? | Microsoft does not offer a single merge command. Consolidation requires creating target identities, migrating data, moving domains, rebuilding policies, reconfiguring applications and re-enrolling devices. |
| Why would a business move between Microsoft 365 tenants? | Mergers, acquisitions, divestitures, company separations, group consolidation, tenant ownership changes, geographic restructuring, brand changes or regulatory separation. |
| Does Microsoft provide native tenant-migration tools? | Yes. Microsoft currently provides cross-tenant mailbox migration, OneDrive migration, SharePoint site migration and coordinated migration through Migration Orchestrator. Availability depends on workload, licence and customer agreement. |
| What is Microsoft Migration Orchestrator? | Microsoft currently describes Migration Orchestrator as a coordinated tenant-to-tenant migration service. It currently supports or previews Exchange Online mailboxes, OneDrive, Teams chats and Teams meetings. |
| Is Migration Orchestrator generally available? | Some workloads may remain in preview. Verify current status in Microsoft documentation before project approval. |
| What does the Cross-Tenant User Data Migration licence cover? | The licence currently supports Exchange Online mailbox migration and OneDrive migration for eligible customers. SharePoint migration has separate licensing. Verify current scope, purchasing channels and plan requirements. |
| Can Exchange Online mailboxes move between tenants? | Yes, for qualifying environments using the native cross-tenant mailbox migration capability. |
| Can shared mailboxes move between tenants? | Verify current cross-tenant support for shared mailboxes in current Microsoft documentation. |
| Can archive mailboxes move between tenants? | Supported for eligible scenarios — verify current requirements and limitations. |
| Can mailboxes on hold be migrated? | Mailboxes subject to certain holds may require legal review or a different migration route. A technical deadline does not override a legal preservation duty. |
| Can OneDrive move between tenants? | Yes, using native cross-tenant OneDrive migration for supported scenarios and licensing. |
| Can SharePoint sites move between tenants? | Yes, using native cross-tenant SharePoint site migration for supported customers. Verify licensing, eligibility and site requirements. |
| Can SharePoint migrate into an existing site? | No — an existing target site cannot be overwritten or merged. The target must be a new site. |
| Can SharePoint migrations run incrementally? | Native cross-tenant SharePoint migration may be one-time rather than incremental — verify current capabilities. |
| Can Teams move between tenants? | Teams migration involves several separate workloads. Chats and meetings may be supported through Migration Orchestrator. Channel structure requires separate handling. |
| Can Teams private chats migrate? | Verify current support via Migration Orchestrator — some capabilities may remain in preview. |
| Can Teams meeting history migrate? | May depend on mailbox and chat migration — verify current behaviour. |
| Can Teams channels migrate? | Channel structure and messages are not moved by SharePoint site migration. Separate tooling or recreation may be required. |
| Do Teams files migrate with SharePoint? | Files stored in Teams reside in SharePoint or OneDrive and follow those workload migration rules. |
| Do Planner plans migrate? | No — Planner plans must be recreated in the target tenant. |
| Do Forms migrate? | No — Microsoft Forms are attached to source-tenant identities and must be rebuilt. |
| Do Power Automate flows migrate? | No — flows are attached to source-tenant identities and must be rebuilt in the target. |
| Do app registrations migrate? | No — app registrations and service principals must be recreated in the target tenant. |
| Do enterprise applications migrate? | No — enterprise applications must be configured in the target tenant with updated secrets and consent. |
| Do Entra object IDs remain the same? | No — each tenant has its own identity objects. Source Entra object IDs do not transfer to the target. |
| Do passwords migrate? | No — users must register authentication methods in the target tenant. |
| Do MFA methods migrate? | No — MFA registration must be completed for the target tenant. |
| Do Conditional Access policies migrate? | No — Conditional Access policies must be created in the target tenant. |
| Can a domain exist in two Microsoft tenants? | A verified custom domain cannot normally remain actively attached to two Microsoft 365 tenants simultaneously. |
| How is a custom domain moved? | Domain dependencies must be removed from the source, the domain removed, then added and verified in the target, with DNS updated accordingly. |
| Will email addresses remain the same? | They can remain the same once the domain is moved to the target tenant and target mailboxes are configured with the correct addresses. |
| Will users need new Outlook profiles? | Yes — users will need new Outlook profiles configured for the target tenant. |
| Will mobile devices need reconfiguration? | Yes — mobile devices need reconfiguring for the new tenant sign-in. |
| Do Intune devices migrate? | No — devices remain enrolled in the source tenant and require re-enrolment in the target. |
| Can Windows Autopilot devices move tenants? | Autopilot registration must be transferred to the target tenant — it does not move automatically. |
| What happens to external guests? | Guests are linked to the source tenant. They may need to be re-invited in the target tenant. |
| What happens to existing sharing links? | Sharing links may change. External recipients may need new access. |
| Can sensitivity-labelled files migrate? | Files with sensitivity labels may be eligible for migration, but certain encryption configurations using Customer Key may block migration. Verify current restrictions. |
| What happens to legal holds? | Mailboxes subject to legal holds require specialist review before migration. The hold must not be removed without legal authorisation. |
| Is a tenant migration the same as backup? | No — migration transfers data between tenants. Backup provides a separate recoverable copy for restoration. |
| How long does a tenant migration take? | Depends on workload volume, complexity, number of workloads, pilot results, application dependencies and coexistence period. Weeks to months for a complete project. |
| Can a tenant migration have zero downtime? | Short disruption periods may be achievable for specific workloads but zero downtime cannot be guaranteed for a complete migration. Coexistence planning and pilot testing reduce disruption. |
| When can the source tenant be closed? | Only after all planned migrations are validated, compliance records are preserved, legal holds are addressed, applications are transferred, devices are moved, backup is confirmed and written business approval is obtained. |
| Does Microsoft FastTrack support tenant migrations? | Microsoft FastTrack may provide guidance or migration support to qualifying customers above a licence threshold. Verify current eligibility, workload support and whether FastTrack performs or assists with migration. |
| Are third-party migration tools still needed? | Third-party tooling may still be appropriate for unsupported workloads, complex environments, SharePoint customisations, Teams channel migration or where native-tool eligibility is not met. |
| What should a tenant-migration assessment include? | Business case, tenant ownership, identity inventory, workload assessment, application inventory, device inventory, compliance review, migration licensing, target design, coexistence plan and decommissioning approach. |
| Can IT Club review a tenant-migration plan? | Yes — use the Ask the Advisor service to ask about tenant consolidation, separation, specific workloads or the assessment process. |
Administrator Technical Note
This note summarises current Microsoft technical concepts for administrators planning a tenant-to-tenant migration. Always verify against current Microsoft documentation before implementation.
Tenant architecture and identity
Each Microsoft 365 tenant has a unique tenant ID in Microsoft Entra ID. Entra user objects have a unique object ID, a user principal name (UPN) and an Exchange GUID. These identifiers are tenant-specific and do not transfer between tenants. Target MailUser objects must be pre-staged in the target Exchange environment with the correct ExchangeGUID and ArchiveGUID from the source before cross-tenant mailbox migration can proceed.
Cross-Tenant Identity Mapping
Microsoft currently provides Cross-Tenant Identity Mapping to help match source and target user objects for migration. This capability establishes the relationship between source and target identities that migration tools use to route data correctly. Verify current availability and whether this remains preview or is generally available.
Migration Orchestrator
Migration Orchestrator is Microsoft's coordinated tenant-to-tenant migration service. It currently supports or previews Exchange Online mailboxes, OneDrive, Teams chats and Teams meetings. It requires Cross-Tenant User Data Migration licensing. Access is through the Microsoft 365 Admin Centre. Orchestrator co-ordinates migration across supported workloads but does not migrate identities, devices, applications, Teams channels, Conditional Access or organisation-wide settings.
Cross-tenant Exchange mailbox migration
Native cross-tenant Exchange mailbox migration requires: organisation relationships configured between source and target tenants; a migration application registered in both tenants with appropriate Exchange Online application permissions; MailUser objects pre-staged in the target with matching ExchangeGUID and ArchiveGUID; source email addresses added as X500 legacy addresses on target MailUser objects to preserve reply continuity; a migration endpoint configured in the target tenant; and migration batches created and monitored. After completion, the source mailbox typically becomes a MailUser pointing to the target.
Mailboxes subject to In-Place Hold, Litigation Hold or certain eDiscovery holds may require hold removal or a compliance review before migration is eligible. Verify the precise current rule in Microsoft documentation.
Cross-tenant OneDrive migration
Cross-tenant OneDrive migration requires: source and target Global Administrators with appropriate permissions; Cross-Tenant User Data Migration licensing per user; target OneDrive provisioned for each user; identity mapping established; and migration batches created. Sharing links and external permissions may be affected. Version history and supported metadata transfer; some encryption configurations may restrict eligibility.
Cross-tenant SharePoint migration
Cross-tenant SharePoint site migration requires: separate SharePoint-specific licensing (verify current per-user or data-volume model and eligibility); source and target administrator access; target sites that do not already exist (existing sites cannot be overwritten or merged); and prerequisites for both source and target tenants. Site migration is not the same as SharePoint content migration between libraries within a tenant. Site size, item count and other limits apply; verify current maximums. Some capabilities may be one-time rather than incremental. Teams-connected sites migrate SharePoint content but do not recreate the Teams channel structure or Team object.
Teams chats and meetings
Migration Orchestrator may support selected Teams chat and meeting data. Teams channel migration and channel-message history are separate from Teams chat migration and are not moved by SharePoint site migration. Private-channel SharePoint sites require separate assessment. Verify current Migration Orchestrator Teams capabilities, preview status and scope before project planning.
Microsoft 365 groups and Teams objects
A Microsoft 365 group-connected SharePoint site can be migrated; the group itself and the associated Team are not automatically recreated in the target. Teams must be recreated and membership reassigned. Dynamic-group rules must be rebuilt. Distribution lists and mail-enabled security groups must be created in the target Exchange environment.
Custom-domain movement
A custom domain cannot be actively assigned to two tenants simultaneously. All UPNs, email addresses, aliases, group addresses and application references using the domain must be updated before domain removal from the source. The domain is then removed from the source, added to the target, DNS-verified, and users and groups assigned their target addresses. MX, SPF, DKIM and DMARC records must be updated for the target tenant.
Cross-tenant access settings
Microsoft Entra cross-tenant access settings (External Identities > Cross-tenant access settings) allow per-organisation configuration of inbound B2B collaboration, MFA-claims trust, compliant-device claims and hybrid-joined-device claims. These settings can enable users in both tenants to collaborate during coexistence without requiring full re-authentication. They do not replace migration; they support the coexistence period.
Application registration migration
App registrations, enterprise applications and service principals are tenant-specific objects. They cannot be moved; they must be recreated in the target tenant. New client secrets or certificates must be generated, redirect URIs updated, API permissions granted and admin consent applied. Applications using managed identities require new managed identities in the target. User and group assignments must be recreated.
Device migration
Entra-joined devices are joined to a specific tenant. They cannot be migrated by user-data migration. Re-joining or re-enrolling devices in the target tenant typically requires a device reset or an off-boarding and on-boarding process. Autopilot hardware hashes registered to the source tenant must be transferred to the target. Intune compliance policies, configuration profiles, application deployments and BitLocker recovery keys are tenant-specific and must be configured in the target.
Sensitivity labels and encryption
Sensitivity labels are published from the source Microsoft Purview environment. Labels using Microsoft Purview Customer Key or specific encryption configurations may prevent SharePoint site migration. Labels must be recreated in the target Microsoft Purview environment and files relabelled or verified after migration. Documents encrypted with source-tenant labels may require access via source-tenant credentials until relabelled.
Licensing
The Cross-Tenant User Data Migration licence is currently required for Exchange Online mailbox migration and OneDrive migration per eligible user. SharePoint migration has separate licensing requirements. Availability depends on the Microsoft 365 plan, purchasing channel (CSP, Enterprise Agreement, web-direct, education) and customer eligibility. Do not assume every plan or channel qualifies — verify with Microsoft licensing documentation or a Microsoft partner before project approval.
FastTrack
Microsoft FastTrack may provide guidance or migration support to qualifying organisations above a licence threshold. FastTrack typically assists rather than performs migrations directly. Eligibility, supported workloads, exclusions and current cross-tenant preview status should be verified. FastTrack is not generally available to all small organisations.
Last checked: 4 August 2026. All technical details, tool availability, licensing requirements, workload support and configuration requirements should be verified against current Microsoft documentation before implementation.
Operational Heartbeat
The target environment will continue changing after migration completes. Users join and leave, source accounts remain, guests accumulate, delegated access changes, licences renew, SharePoint permissions drift, Teams ownership changes, applications retain old secrets, devices fail to enrol, old domains remain, source licences continue billing, migration exceptions are forgotten, backup authentication changes and compliance obligations evolve.
A tenant migration needs an Operational Heartbeat: identities, domains, licences, applications, devices, permissions, backup, unresolved migration items and remaining source dependencies should be reviewed rather than assumed to have disappeared.
A recurring review after a tenant migration should check: source and target administrators; emergency access accounts; remaining source users; unresolved migration failures; custom domains; DNS; licences; guest accounts; cross-tenant access settings; application registrations and certificates; devices; Intune enrolment; SharePoint permissions; Teams ownership; external sharing; retention; legal holds; backup coverage; restore testing; supplier access; source-tenant closure plan; corrective actions; and next review date.
Plain-English Takeaway
A Microsoft 365 tenant-to-tenant migration moves supported email, OneDrive, SharePoint and selected Teams data between two separate Microsoft cloud organisations. It does not automatically move identities, domains, devices, applications, policies or every collaboration feature. Businesses should assess each workload, map users carefully, secure the target, pilot the migration, plan the domain cutover and retain the source tenant until data, access, compliance and recovery have been validated.
Need the practical steps?
A short, instruction-led version of this topic is available in the Knowledge Centre.
View the Knowledge Centre GuideRelated Articles
Moving from Google Workspace to Microsoft 365: What Businesses Need to Plan
Moving from Google Workspace to Microsoft 365 involves email, calendars, contacts, files, identities, permissions, applications, devices and user behaviour — not merely copying Gmail into Outlook. Microsoft now provides native migration tools for supported workloads, but the business must still assess its data, design the destination, test representative users, secure the tenant and retain Google Workspace until migration and recovery checks are complete.
Read articleCan You Move Microsoft 365 Away from Your Current Provider?
Many businesses want to change their Microsoft 365 IT provider but do not know whether they own their own tenant, who holds Global Administrator access, or what exit route applies. The answer may be a simple licence change, a CSP subscription transfer, a supported defederation, or a full tenant migration. These are not the same project, and the wrong sequence can cause serious disruption.
Read articleHow Do You Prove Your Business Can Be Trusted?
Every business claims to be reliable, professional and secure. But how can a customer, supplier or partner actually tell? Independent certification provides evidence that goes beyond marketing claims.
Read article