A Microsoft 365 tenant-to-tenant migration moves identity first, content second, and endpoints last. Microsoft now ships a Migration Orchestrator for mailboxes, OneDrive and Teams chats — but not for SharePoint sites, Teams channels, Intune or Power Platform. EPC Group has run 216+ M&A tenant migrations covering 1.83M users.
Last updated: 2026-07-31
EPC Group is a Houston-based Microsoft consulting firm operating since 1997, with six Microsoft Solutions Partner designations and 216+ M&A tenant migrations covering 1.83M users. Governed Microsoft AI, Data & Cloud — since 1997.
Key facts
- Microsoft's Migration Orchestrator moves four workloads: Exchange mailboxes, OneDrive, Teams chats and Teams meetings. Teams chats and meetings are in preview. It moves content, not identities — you create and configure every target user yourself.
- The Orchestrator does not move shared data: Teams, channels, and SharePoint sites stay in the source tenant and need a separate migration path.
- Cross-Tenant User Data Migration is a per-user, one-time-fee add-on that covers mailbox and OneDrive moves, and can be assigned on either the source or the target user object. Migrations fail without it and Microsoft publishes no exceptions.
- Cross-tenant SharePoint site migration is licensed separately, per 100 GB of data moved, and is currently available only to Enterprise Agreement customers, with a 20% storage grace allowance.
- Microsoft's published cross-tenant mailbox durations: 0–10 GB, 1 day at both P50 and P90; 10–50 GB, 1 and 2 days; 50–100 GB, 2 and 5 days; 100–200 GB, 3 and 6 days. Above 200 GB is not supported.
- Mailboxes on any type of hold are blocked from migration. So are OneDrive accounts under a hold policy. Remediating holds is a legal workstream, not an IT task, and it is usually the critical path.
- Batch guidance: do not exceed 2,000 mailboxes per batch, and submit batches roughly two weeks before cutover — synchronization has no end-user impact.
- A domain can only be owned by one tenant. Removal from the source can take as little as five minutes or, where many objects reference the domain, several hours up to a day.
Quick facts
| Question | Answer |
|---|---|
| Native orchestration exists? | Yes — Microsoft 365 Migration Orchestrator |
| Workloads it covers | Exchange mailboxes, OneDrive, Teams chats (preview), Teams meetings (preview) |
| Workloads it does not cover | SharePoint sites, Teams and channels, Microsoft 365 Groups, Planner, Power Platform, Intune |
| Identity migration included? | No — content only; you pre-create and map every user |
| Licence required | Cross-Tenant User Data Migration, per user, one-time fee |
| SharePoint site licence | Cross-Tenant Shared Data Migration, per 100 GB, EA customers |
| Incremental/delta passes | Not supported for OneDrive or SharePoint — one-and-done moves |
| Mailbox batch ceiling | 2,000 per batch |
| Hard blocker | Any hold on a mailbox or OneDrive account |
| Cross-cloud (WW → GCC) | Not supported |
| Typical enterprise elapsed time | 4–9 months for 5,000+ users, single acquisition |
What Microsoft native tooling actually covers in 2026
Start here, because the answer changed recently and most published guidance predates it.
Microsoft now ships three distinct native capabilities, and they are not one product. Cross-tenant mailbox migration uses Exchange Online PowerShell and MRS with an Entra app registration, a migration endpoint and an organization relationship. Cross-tenant OneDrive and SharePoint migration use SharePoint Online PowerShell, a Set-SPOCrossTenantRelationship trust, and an uploaded identity map. Migration Orchestrator sits on top and coordinates mailboxes, OneDrive, Teams chats and Teams meetings into a single dependency-ordered batch.
Two limits define the entire program. First, the Orchestrator migrates content, not identities — Cross-Tenant Identity Mapping (CTIM) writes ExchangeGuid, ArchiveGuid, LegacyExchangeDN and proxy addresses onto target MailUser objects, but you still create and licence every user. Second, the Orchestrator explicitly excludes shared data: Teams, channels, and SharePoint sites. Learn's own tenant-to-tenant landing page says the Orchestrator covers SharePoint. The Orchestrator's overview page says it does not. Build your plan against the Orchestrator page.
Everything outside those four workloads — Entra groups and application registrations, Intune, Power Platform, Power BI, Planner, public folders, Purview labels — has either a separate native path or no path at all.
The Identity-First Merge Stack
The Identity-First Merge Stack is EPC Group's model for sequencing a tenant migration. Its governing rule: each layer is a hard dependency for the layer above it, and every failed migration we have been called in to rescue skipped or parallelised a layer.
| Layer | What it establishes | Cannot start until |
|---|---|---|
| 1 — Directory | Target users, groups, licences, UPN strategy, mail-enabled security scope groups | Naming and UPN decision is signed off |
| 2 — Identity mapping | CTIM run, ExchangeGuid/ArchiveGuid/X.500 proxies written to target MailUsers | Layer 1 users exist as MailUsers with no mailbox provisioned |
| 3 — Routing and coexistence | Mail flow, free/busy, MailTips, Teams collaboration between tenants | Layer 2 complete; target domains accepted |
| 4 — Personal content | Mailboxes, archives, OneDrive | Layer 2 complete and licences applied in the correct order |
| 5 — Shared content | SharePoint sites, Teams and channels, Microsoft 365 Groups | Layer 4 identity map validated; target sites not pre-created |
| 6 — Platform | Power Platform environments, Power BI content, Purview labels, apps | Layer 1 and Layer 5 complete |
| 7 — Endpoint | Intune enrolment, device join state, Autopilot, app re-sign-in | Layer 3 stable — users need working mail during device work |
Two rules are non-negotiable. Never licence a target user before identity mapping writes the ExchangeGuid — do that and Exchange provisions a brand-new empty mailbox, the MailUser-to-mailbox conversion fails, and you are unpicking objects by hand. And never let OneDrive auto-provision in the target tenant; disable OneDrive site creation for migration-scope users the moment you create them, because a pre-existing target OneDrive fails the move and cannot be overwritten.
The full program: phases, owners, durations
Durations below are EPC Group planning ranges for a 5,000-user single-acquisition consolidation with a hybrid source. They are delivery estimates, not published Microsoft figures. Scale them by user count and by how much of the estate is on hold.
| Phase | What happens | Owner | Typical duration |
|---|---|---|---|
| 0 — Discovery | Inventory both tenants: users, mailbox sizes, holds, OneDrive and site storage, Teams, groups, apps, devices, Power Platform environments, licence position, domains and DNS control | Source + target platform leads | 3–5 weeks |
| 1 — Legal and compliance unblock | Identify every mailbox and OneDrive under litigation hold, retention lock or eDiscovery hold. Agree removal, defensible copy, or exclusion. Confirm data-residency and regulatory position | Legal / records + compliance officer | 4–12 weeks (runs in parallel; usually the critical path) |
| 2 — Target design and build | UPN and domain strategy, licence procurement, Conditional Access, groups, naming, security baseline, tenant settings | Target identity architect | 3–4 weeks |
| 3 — Commercials | Purchase Cross-Tenant User Data Migration licences; confirm EA position for Cross-Tenant Shared Data Migration if SharePoint sites move | Procurement + Microsoft account team | 2–6 weeks lead time |
| 4 — Plumbing | Entra app registrations and cross-tenant admin consent, Exchange migration endpoint, organization relationship, SharePoint trust, CTIM service principal | Both tenant admins, jointly | 1–2 weeks |
| 5 — Coexistence stand-up | Mail routing, free/busy, MailTips, Teams collaboration, cross-tenant sync if users must work across both | Messaging + identity leads | 1–2 weeks |
| 6 — Pilot | 15–30 users spanning a delegate pair, a shared mailbox, a large mailbox, an archive user, a Teams-heavy user. Full validation | Migration lead | 2–3 weeks |
| 7 — Remediation | Fix everything the pilot found: oversized mailboxes, path lengths, sensitivity labels, non-owned SMTP proxies, orphaned OneDrive ownership | Migration lead + workload owners | 3–6 weeks |
| 8 — Production batches | Waves of ≤2,000 mailboxes, submitted ~2 weeks ahead of each completion date. OneDrive and Teams chats in the same batch | Migration lead + service desk | 6–16 weeks |
| 9 — Shared content | SharePoint sites, Teams and channels, Groups. Separate licence, separate tool decision | SharePoint lead | 4–10 weeks, overlapping phase 8 |
| 10 — Cutover weekend | Domain release and re-verification, MX cutover, final delta, comms | Change manager + both tenant admins | One weekend |
| 11 — Endpoint and platform | Intune re-enrolment, device join state, Power Platform and Power BI, app reconnection | Endpoint lead + app owners | 4–12 weeks, post-cutover |
| 12 — Decommission | Remove trusts, org relationships, migration endpoints, CTIM data, redirects. Source tenant wind-down | Both tenant admins | 2–4 weeks |
Phase 1 is the one CIOs underfund. Holds block mailboxes and OneDrive accounts outright, and only Legal can lift them. Start it in week one.
Why identity sequencing decides everything
Identity is not a phase you can run in parallel — it is the substrate every other workload writes into.
The mechanism is precise. A cross-tenant mailbox move requires the target user to exist as a MailUser, not a mailbox, stamped with the source mailbox's ExchangeGuid, ArchiveGuid, LegacyExchangeDN as an X.500 proxy, and every other X.500 proxy from the source. CTIM writes those attributes for you. If a licence lands on that object before the attributes are written, Exchange provisions a fresh mailbox and the conversion fails. Microsoft's guidance is explicit: assign Exchange licences after migration completes, during the grace period.
The same logic governs content. Cross-tenant OneDrive and SharePoint moves consume an identity map — a CSV uploaded to the target tenant that maps each source user and group to exactly one target user or group. Permissions survive only for principals present in that map. Any user or group missing from it loses access to migrated content, silently. Upload a revised map and it overwrites the previous one entirely, so every revision must contain the full population, not the delta.
If you keep an on-premises Active Directory, two Entra Connect instances can synchronise to two tenants. Use selective OU sync rather than the pre-provisioning script, expect a UPN-mismatch warning during configuration, and verify msExchMailboxGUID and proxyAddresses are correct on-premises before syncing — otherwise you create double mailboxes. Related reading: Microsoft 365 E3 vs E5 for the licence position you are buying into, and Exchange to Microsoft 365 migration for the hybrid mechanics underneath.
The coexistence period — where projects actually fail
Coexistence is the phase nobody budgets and everybody lives in. From the moment the first user moves to the moment the last one does, you are running one company on two tenants, and the failure mode is not data loss — it is that people cannot book a meeting with each other.
Mail routing is automatic and one-directional. After a successful move, the source mailbox is deleted, the source object converts to a MailUser, and targetAddress is stamped with the routing address in the target tenant. Mail sent to the old address forwards. Note the consequence: inbound mail is processed by the source tenant's transport rules, anti-spam, quarantine and journaling first, then by the target's. Two policy sets, two quarantines, two sets of tickets.
Free/busy is the thing that breaks. Historically this ran on an Exchange organization relationship or an Availability Address Space. Microsoft is now replacing both — along with sharing policies — with Microsoft 365 Cross-Tenant Access Policy for free/busy, shared calendars and MailTips, because Exchange Web Services is being deprecated in Exchange Online and high-privilege access patterns are being removed. If you are scoping a migration in 2026, build coexistence on Cross-Tenant Access Policy where it has reached your tenant, and check Message Center for rollout status before you design around the legacy objects.
Delegates cannot span the boundary. Cross-tenant mailbox and calendar permissions are not supported. Mailbox permissions survive only when the principal and the delegate move in the same batch. Send-on-Behalf (publicDelegates) does not move at all and must be re-stamped on the target with Set-Mailbox -GrantSendOnBehalfTo. Practical consequence: your batch design is not driven by department or geography. It is driven by the delegation graph. Map executives, assistants, shared mailboxes and room resources into consolidated waves before you write a single batch.
Teams degrades in the source tenant after the mailbox moves. Users signing in with source credentials lose calendar, cannot update their profile picture, and cannot search or join public teams. For coexistence across a long consolidation, stand up cross-tenant collaboration deliberately: Entra cross-tenant synchronization (Entra ID P1 or P2 in both tenants, ~40-minute cycles, does not sync devices or contacts) provisions B2B member users so people are discoverable in the global address list, and a multitenant organization plus the Teams collaboration setting gives cross-tenant chat, calling and meeting scheduling. See our Teams Premium feature guidance for the licensing layer above this.
Coexistence accrues debt: duplicate licences, duplicate security tooling, two service desks, two policy sets. Track it as a line item and treat shortening it as a funded objective.
What moves, what doesn't, what you rebuild
| Workload | What moves natively | What does not move | What you rebuild |
|---|---|---|---|
| Exchange Online | Email, calendar, contacts, tasks, notes, server-side rules, archives and auxiliary archives (max 12), recoverable items, room and equipment mailboxes, voicemail | Public folders, mailboxes on any hold, client-side rules, Outlook profiles, signatures, Send-as, Send-on-Behalf, auto-mapping, Microsoft 365 Groups | Delegation, signatures, transport and journaling rules, retention tags, Outlook profiles (users rebuild with new UPN and re-sync the OST) |
| OneDrive | Files, folder structure, user and group permissions, sharing links, version history, created/modified/created-by metadata; redirect left on source | Accounts on hold, accounts >5 TB or >1M items, paths >400 characters, incremental passes | Sync client re-sign-in on every device; any permission for a principal missing from the identity map |
| SharePoint | Group-connected, modern, classic and communication sites; documents, structure, permissions, sharing links, versions, basic metadata | Sites >5 TB or >1M items, workflows (2010/2013), apps, Power Apps and automation tasks, sensitivity labels with user-defined permissions | Workflows, apps, Power Automate connections, web parts referencing other sites or services, labels |
| Teams | Chats and meetings via the Orchestrator (preview) | Teams, channels, channel files as Teams objects, tabs, apps, Planner boards | Team and channel structure, tabs, apps, membership, Planner plans |
| Entra ID | Nothing. Cross-tenant sync creates B2B users, not a migration | Users, security groups, application registrations, service principals, Conditional Access, PIM, devices, contacts | The entire directory, by design |
| Intune | Nothing. No supported device migration path | Device enrolment, compliance state, some policy types including certificate profiles | Unenrol from source, re-enrol in target. Hybrid-joined to Entra-joined requires a Windows reset — there is no supported in-place conversion |
| Power Platform | Dataverse-backed production and sandbox environments move via a source-request / target-approve flow | Default, developer, trial and Teams environments; security groups; some connectors and settings | Security groups, managed-environment enablement, connections, environment settings |
| Power BI | No cross-tenant content move. Side-by-side rebuild or tenant split | Workspaces, semantic models, gateways, capacities | Workspaces, models, reports, gateways, capacities of equal or higher SKU in the target |
| Purview | Nothing | Retention labels and policies, sensitivity labels, DLP, eDiscovery holds and cases | Full label taxonomy and policy set in the target; source-tenant eDiscovery against a migrated mailbox no longer works |
Two entries deserve emphasis. Intune has no migration. Every managed device is unenrolled and re-enrolled, and every hybrid-joined Windows device that you want Entra-joined needs a wipe. Budget the field effort — this is usually the largest labour line in the whole program. And Entra is a rebuild, not a move. Cross-tenant synchronization is a collaboration feature, not a migration tool.
The cutover weekend runbook
Cutover is the domain move. Everything else is batching.
T-14 days. Final mailbox batches submitted. Reduce DNS TTLs on MX, autodiscover and SPF to 300 seconds. Freeze new mailbox, group and site creation in the source tenant. Confirm every migration-scope object is in a terminal state.
T-7 days. Comms wave: new UPN, new primary SMTP, "you will rebuild your Outlook profile", named support channel, exact window. Confirm Legal has cleared every remaining hold. Confirm the target tenant has licences in stock.
T-2 days. Dress rehearsal on a test domain. Verify target proxy addresses contain no SMTP domain the target tenant does not own — a non-owned proxy blocks the MailUser-to-mailbox conversion outright.
Friday 18:00 — freeze. Stop all migrations. Take a directory export from both tenants. Snapshot DNS.
Friday 19:00 — strip the source domain. Move every remaining user, group, distribution list, shared mailbox, resource mailbox and alias off the custom domain onto .onmicrosoft.com — use PowerShell, not the portal, or the UI will miss objects and the removal will fail. Confirm the domain is not the default and no admin signs in with it.
Friday 21:00 — remove the domain from source. This is the irreversible step. Removal can complete in five minutes or take several hours to a day depending on how many references exist. It is why the domain-strip must be complete before you start.
Saturday — add and verify in target. Add the domain, publish the TXT record, verify, set as default where required, assign to users, republish MX, SPF, DKIM and DMARC. This is the longest-pole item on the weekend and it is DNS-propagation bound.
Saturday afternoon — final delta and validation. Any remaining moves complete. Validate a scripted checklist: send/receive both directions, free/busy, Teams sign-in, OneDrive sync, a SharePoint site, a room booking, a shared mailbox, a delegate pair, MFA registration.
Sunday — service desk surge. Staff it at three to five times normal. Publish two answers in advance because they generate most of the volume: rebuild your Outlook profile with your new address, and sign in to OneDrive again to restart sync.
Abort criteria. If the domain does not release from source by Saturday 06:00, stop. Do not add MX records for a domain you cannot verify. Roll forward to the next window, keep coexistence running, and communicate a new date — a failed domain cutover is a full mail outage, and it is the one failure in this program with no clean rollback.
What breaks — failure modes
| Symptom | Root cause | Fix |
|---|---|---|
| Migration fails: "A Cross-tenant User Data Migration license is required" | The per-user migration add-on is not assigned to source or target object | Purchase and assign the licence. Microsoft publishes no exceptions to this requirement |
| Mailbox move blocked with no obvious error | Mailbox is on litigation, retention or eDiscovery hold | Legal must release the hold, or the user is excluded. This is why hold remediation starts in phase 1 |
| Target user ends up with a new empty mailbox | Exchange licence applied before identity mapping wrote ExchangeGuid | Remove the licence and the object, recreate as MailUser, re-run CTIM, licence after migration |
| MailUser will not convert to a mailbox | Target MailUser carries an SMTP proxy for a domain the target tenant does not own | Strip every non-owned SMTP proxy from the target object before the move |
| OneDrive migration fails immediately | A OneDrive site already exists for that user in the target | Disable OneDrive creation for migration-scope users at creation time. You cannot overwrite an existing site |
| SharePoint site migration fails | Target site already exists, or site is read-only, or site exceeds 5 TB / 1M items | Never pre-create target sites. Set source sites to Read/Write. Split or archive oversized sites first |
| Files silently missing after a content move | Path exceeded 400 characters once combined with the new target URL | Shorten target site and user URL names; restructure deep folders before the move |
| Site with encrypted files will not migrate | Sensitivity label configured for user-defined permissions | Remove labels pre-migration (Unlock-SPOSensitivityLabelEncryptedFile), migrate, reapply in the target |
| Users lose access to migrated content | The user or group was absent from the identity map | Rebuild the map with the complete population and re-upload — a new map overwrites the old one entirely |
| Executive loses access to an assistant's calendar | Cross-tenant mailbox and calendar permissions are unsupported; principal and delegate moved in different batches | Rebuild batches around the delegation graph; re-stamp Send-on-Behalf after the move |
| Outlook will not connect on Monday morning | The old primary SMTP address no longer resolves in the target; the Outlook profile still expects it | Users rebuild the profile with the new UPN and re-sync the OST. Warn about network load when thousands do this at once |
| Source tenant cannot run eDiscovery on a migrated user | The source mailbox is deleted on successful migration | Copy the mailbox contents to an alternate source mailbox before migrating if the source needs future discovery |
Cost and effort drivers
There is no list price for a tenant migration, but there are five drivers that determine the number, and four of them are not tooling.
Licensing is the smallest line. Cross-Tenant User Data Migration is a one-time per-user fee covering mailbox and OneDrive, assignable on either side. Cross-tenant SharePoint site migration is licensed separately, per 100 GB moved, with a 20% storage grace allowance, and is currently EA-only — price it from Get-SPOSite | Select-Object Url, StorageUsageCurrent summed across in-scope sites. Both are quoted by your Microsoft account team, not published.
Coexistence duplication is the biggest recurring line. Every month you run two tenants, you pay twice for licences, security tooling and administration. A 5,000-user consolidation running nine months of coexistence spends more on duplication than on every migration licence combined. Shorten the window; it is the highest-leverage cost decision in the program.
Legal and compliance remediation is the biggest hidden line. Holds block migration. Reviewing, releasing and re-applying holds across thousands of mailboxes is counsel time, and it does not compress with more engineers.
Endpoint labour is the biggest people line. No Intune migration path means every device is touched, and hybrid-joined devices you want Entra-joined get wiped. Multiply device count by touch time and add the user-productivity hit.
Remediation before migration is where the schedule goes. Oversized mailboxes, 400-character paths, encrypted files, orphaned OneDrive ownership, non-owned proxies, workflows and InfoPath forms. Discovery-and-remediation routinely consumes more calendar time than the data movement. If your plan does not have a remediation phase, it has an overrun.
Our Microsoft 365 E3 vs E5 comparison works the target-licence decision, and SOC 2 compliance for Microsoft 365 covers the evidence obligations that survive the move.
What changed in 2026
- Microsoft 365 Migration Orchestrator is documented as a first-party product with its own planning, prerequisites, tenant-config, post-migration and FAQ pages, plus a prevalidation check table that cancels a batch before it runs. If you scoped a tenant migration before this, re-scope it.
- Cross-Tenant Identity Mapping (CTIM) is a supported PowerShell module with a five-phase workflow — scope, copy, map, write, remove. It is mandatory for orchestrated migrations and optional for standalone mailbox moves.
- Cross-Tenant Access Policy is replacing Organization Relationship, Availability Address Space and Sharing Policies for free/busy, shared calendars and MailTips, driven by EWS deprecation in Exchange Online. Coexistence designs built on the legacy objects have an expiry date.
- Teams chat and meeting migration exists, in preview, inside the Orchestrator — with hard prerequisites including Teams licences on both tenants, autoforwarding enabled in the outbound spam filter policy on both tenants, and correctly provisioned migration apps.
- Power Platform tenant-to-tenant environment move reached general availability on 31 July 2025, with a source-request / target-approve flow and a seven-day request expiry.
- Microsoft published a Power BI tenant migration patterns guide naming three distinct scenarios — side-by-side, tenant split, tenant remap — and stating that a remap takes about three hours with delays of up to 24 hours possible.
- FastTrack offers a cross-tenant migration service in preview: invitation-only, minimum 150 licences, Cross-Tenant User Data Migration SKU required, and explicitly excluding Teams, Microsoft 365 Groups, Planner, Stream, Power Automate, Power Apps, device management and client configuration.
Where to go next
If you are on the acquiring side of a deal, the migration plan is due before the close, not after it. EPC Group runs the discovery, hold-remediation triage, Merge Stack readiness assessment and a dated cutover runbook as a fixed-scope engagement, then delivers the migration. Start with enterprise Microsoft consulting or Azure cloud migration consulting.
Related: Exchange to Microsoft 365 migration · SharePoint migration services · SharePoint consulting Dallas · My Sites in SharePoint · Microsoft 365 E3 vs E5 · Power Platform consulting firms · Power BI consulting · Azure Virtual Desktop deployment · Delivery partner vendor risk · Microsoft Frontier Company · EPC Group
Frequently asked questions
Does Microsoft have a native tenant-to-tenant migration tool?
Yes. The Microsoft 365 Migration Orchestrator coordinates Exchange mailboxes, OneDrive, Teams chats and Teams meetings in dependency-ordered batches, and standalone cross-tenant tools exist for mailbox, OneDrive and SharePoint site moves. The Orchestrator moves content, not identities, and does not move shared data such as SharePoint sites or Teams channels.
How long does a tenant-to-tenant migration take?
For a 5,000-user single-acquisition consolidation, plan four to nine months end to end. Microsoft publishes cross-tenant mailbox durations of one day at P50 and P90 for mailboxes under 10 GB, rising to three days at P50 and six at P90 for 100–200 GB. The long poles are usually legal hold remediation and endpoint re-enrolment, not data movement.
What blocks a mailbox from migrating?
Any type of hold. Mailboxes on litigation, retention or eDiscovery hold are blocked outright and the move is refused. OneDrive accounts under a hold policy are blocked the same way. Releasing holds is a legal decision, so start that workstream in the first week of the project.
Do SharePoint sites and Teams move with the Orchestrator?
No. The Orchestrator explicitly excludes shared data such as Teams, channels and SharePoint sites. Cross-tenant SharePoint site migration is a separate capability with separate licensing, and Teams and channel structure has no native cross-tenant path at all — it is rebuilt or moved with a third-party tool.
What licence do I need for a cross-tenant migration?
Cross-Tenant User Data Migration, a per-user one-time-fee add-on that covers mailbox and OneDrive moves and can be assigned on either the source or the target user object. Migrations fail without it and Microsoft offers no exceptions. Cross-tenant SharePoint site migration needs Cross-Tenant Shared Data Migration licences, sold per 100 GB moved to Enterprise Agreement customers.
Can users keep the same email address?
Only after the domain moves. A domain can be owned by exactly one tenant, so the source and target tenants must use different domains until cutover. Removing the domain from the source can take five minutes or several hours up to a day depending on how many objects reference it, which makes the cutover window a hard deadline.
What happens to Intune-managed devices?
There is no supported device migration path. Devices are unenrolled from the source tenant and re-enrolled in the target. Some Intune policies can be exported and imported with Microsoft Graph scripts, but not all — certificate profiles are one documented exception. Converting a hybrid Entra joined device to Entra joined requires a Windows reset.
Does free/busy work between the two tenants during migration?
Yes, if you configure it. Historically this used an Exchange organization relationship or an Availability Address Space. Microsoft is now moving free/busy, shared calendars and MailTips to Microsoft 365 Cross-Tenant Access Policy because Exchange Web Services is being deprecated in Exchange Online, so build new coexistence on Cross-Tenant Access Policy once it reaches your tenant.
Why do delegate permissions break after migration?
Cross-tenant mailbox and calendar permissions are not supported. Mailbox permissions survive only when both the principal and the delegate move in the same batch, and Send-on-Behalf is stored in the directory and does not move at all. Build migration batches around the delegation graph and re-stamp Send-on-Behalf on the target after the move.
Do we need a third-party migration tool?
It depends on scope. If you are moving mailboxes, OneDrive and Teams chats between two commercial-cloud tenants, the native path is capable and cheaper. If you need Teams and channel structure, Microsoft 365 Groups, Planner, public folders, incremental and delta passes, or a merge into existing target sites, the native path does not do those things and a third-party tool is the realistic answer.
What is the single most common cause of failure?
Licensing target users before identity mapping has written the Exchange GUID. That provisions a new empty mailbox in the target, breaks the MailUser-to-mailbox conversion, and has to be unpicked object by object. Assign workload licences after migration, during the grace period.
Sources and verification
- Microsoft Learn — Plan a Microsoft 365 tenant-to-tenant migration
- Microsoft Learn — Microsoft 365 migration overview
- Microsoft Learn — An overview of tenant-to-tenant migration with orchestrator in Microsoft 365
- Microsoft Learn — Migration orchestrator: planning and prerequisites
- Microsoft Learn — Migration orchestrator: configuring source and target tenants
- Microsoft Learn — Migration orchestrator: post-migration tasks and cleanup
- Microsoft Learn — Cross-Tenant Identity Mapping
- Microsoft Learn — Cross-tenant mailbox migration
- Microsoft Learn — Cross-tenant OneDrive migration
- Microsoft Learn — Cross-tenant SharePoint migration
- Microsoft Learn — Microsoft 365 and Office 365 email migration performance and best practices (P50/P90 cross-tenant duration table)
- Microsoft Learn — Migrate to Microsoft 365 Cross-Tenant Access Policy for sharing Free/Busy, Calendars, and MailTips
- Microsoft Learn — Deprecation of EWS in Exchange Online
- Microsoft Learn — Create an organization relationship in Exchange Online
- Microsoft Learn — What is cross-tenant synchronization?
- Microsoft Learn — Configure cross-tenant synchronization
- Microsoft Learn — Multitenant organization capabilities in Microsoft Entra ID
- Microsoft Learn — Plan for multitenant organizations in Microsoft 365
- Microsoft Learn — Manage multitenant org settings
- Microsoft Learn — Remove a domain from Microsoft 365
- Microsoft Learn — Migration guide: Set up or move to Microsoft Intune (tenant-to-tenant section)
- Microsoft Learn — Microsoft Entra joined vs. Hybrid Microsoft Entra joined in cloud-native endpoints
- Microsoft Learn — Power Platform tenant-to-tenant migrations
- Microsoft Learn — Power BI tenant migration patterns and strategies
- Microsoft Learn — FastTrack cross-tenant migration
- Microsoft Learn — Learn about retention policies and retention labels