Tenant-to-Tenant Migration: Complete M365 Guide

When Tenant-to-Tenant Migration Becomes Necessary

Tenant-to-tenant migration is one of the most complex technical projects in the Microsoft 365 ecosystem. It occurs when two separate Microsoft 365 tenants need to become one — typically during mergers, acquisitions, divestitures, or organizational restructuring. Unlike a simple SharePoint migration, tenant-to-tenant involves every Microsoft 365 workload simultaneously: Exchange Online, SharePoint Online, OneDrive, Teams, Azure AD/Entra ID, Power Platform, and more.

In our 25+ years managing enterprise SharePoint and Microsoft 365 for Fortune 500 companies, we have led tenant-to-tenant migrations for organizations ranging from 500 to 80,000 users. The projects that succeed plan for 6-12 months. The projects that fail try to do it in 6 weeks.

---

Pre-Migration: Assessment and Planning

Tenant Discovery

Both tenants must be thoroughly inventoried before any migration planning begins:

Identity inventory:

• Total user count in each tenant (licensed and unlicensed)
• Guest user accounts and external sharing relationships
• Custom domains registered in each tenant
• Azure AD/Entra ID custom attributes, dynamic groups, and conditional access policies
• Multi-factor authentication configurations
• Privileged Identity Management roles and assignments

Workload inventory:

| Workload | Source Tenant Data Points | Target Tenant Data Points |

|----------|--------------------------|--------------------------|

| Exchange Online | Mailbox count, sizes, shared mailboxes, distribution groups, mail flow rules | Same + capacity planning |

| SharePoint Online | Site collections, total storage, custom solutions, hub sites | Same + architecture mapping |

| OneDrive | User count, total storage, sharing policies | Same + storage capacity |

| Teams | Team count, channel count, private channels, apps, policies | Same + policy alignment |

| Power Platform | Flows, apps, environments, connections, gateways | Same + connector availability |

| Azure AD | Apps, enterprise applications, app registrations, B2B relationships | Same + app compatibility |

Domain Strategy

Domain management is the most underestimated complexity in tenant-to-tenant migration. A domain can only exist in one tenant at a time. When you remove a domain from the source tenant, all users with that domain's UPN lose access until the domain is added to the target tenant.

Domain cutover options:

• Big bang: Remove domain from source, add to target, and migrate all users at once. Fastest but highest risk.
• Temporary UPN: Assign users in the source tenant a temporary UPN ([email protected]), remove the domain, add it to the target tenant, then migrate users. Allows staggered migration but requires temporary email forwarding.
• Subdomain staging: Create a temporary subdomain (migration.company.com) in the target tenant and migrate users to that UPN first, then batch-rename UPNs after the primary domain is moved.

---

Phase 1: Coexistence (Weeks 1-8)

Mail Coexistence

During migration, users in both tenants need to exchange email seamlessly. Recipients in the source tenant must be able to send email to migrated users in the target tenant, and vice versa, without knowing which tenant a user is in.

Mail flow configuration:

• Configure mail-enabled contacts or mail users in each tenant for users in the other tenant
• Set up centralized mail transport rules to route mail between tenants
• Configure calendar free/busy sharing between tenants using organization relationships
• Test email delivery, calendar sharing, and address book resolution before migration begins

Directory synchronization:

• Sync a subset of user attributes from source tenant to target tenant using Azure AD Connect or cross-tenant sync
• Ensure Global Address List (GAL) in both tenants shows users from both organizations
• Configure cross-tenant access settings in Azure AD for Teams and SharePoint coexistence

Teams Coexistence

Teams coexistence between tenants is limited but improving. In 2026, cross-tenant capabilities include:

• Shared channels: Users from both tenants can participate in shared channels without switching tenants
• External access (federation): Users can chat and call across tenants
• Cross-tenant meeting: Users from both tenants can schedule and join meetings seamlessly
• Limitations: Teams membership, channel history, and files do not automatically migrate — they must be recreated or migrated using tools

SharePoint Cross-Tenant Access

Configure SharePoint cross-tenant access policies to allow users in the source tenant to access SharePoint content in the target tenant during the coexistence period:

• Enable cross-tenant access in both tenants' Azure AD external collaboration settings
• Configure SharePoint sharing policies to allow authenticated users from the partner tenant
• Test access with pilot users before announcing cross-tenant capabilities broadly

---

Phase 2: Identity Migration (Weeks 4-12)

User Account Migration

User accounts are migrated from the source tenant to the target tenant. This is not a simple copy — it involves creating new accounts, matching attributes, and managing the transition carefully.

Migration approaches:

• Manual creation: Suitable for small migrations (under 100 users). Create accounts in target, copy attributes.
• PowerShell scripting: Export users from source with Get-MgUser, transform attributes, create in target with New-MgUser.
• Migration tools: BitTitan, ShareGate, AvePoint, and Quest provide automated user migration with attribute mapping.
• Cross-tenant synchronization (preview): Microsoft's native cross-tenant sync automatically provisions users in the target tenant based on source tenant identities.

Critical attributes to map:

• DisplayName, Mail, UserPrincipalName
• Department, Title, Manager, Office, Phone
• Custom extension attributes (used for dynamic group membership, conditional access)
• Profile photos and OneDrive site URLs
• License assignments (source and target may have different SKUs)

Group Migration

Groups are often more complex than individual users:

• Microsoft 365 groups: Recreate in target tenant, add migrated members, migrate associated SharePoint site and Teams team
• Security groups: Recreate with mapped membership, update conditional access policies
• Distribution groups: Recreate with mapped membership, update mail flow rules
• Dynamic groups: Recreate rules using target tenant attributes (verify attribute availability)

---

Phase 3: Workload Migration (Weeks 8-20)

Exchange Online Migration

Mailbox migration is typically the most time-sensitive workload because email downtime is immediately visible to users:

• Use cross-tenant mailbox migration (native Microsoft feature, GA since 2023) for zero-downtime mailbox moves
• Migrate shared mailboxes, resource mailboxes (rooms, equipment), and public folders
• Recreate mail flow rules, transport rules, and DLP policies in the target tenant
• Migrate email signatures, auto-replies, and delegate permissions
• Plan for 2-5 GB/hour migration throughput per migration endpoint

SharePoint Online Migration

SharePoint migration in a tenant-to-tenant scenario involves:

• Site mapping: Map every source site collection to a target location (new URL, new hub association)
• Content migration: Use ShareGate, AvePoint, or BitTitan to migrate content with metadata, versions, and permissions
• Permission re-mapping: Source tenant groups and users must be mapped to target tenant identities
• Hub site restructuring: Merge hub architectures from both tenants into a unified structure
• Custom solutions: SPFx solutions must be redeployed to the target tenant app catalog

For SharePoint-specific migration support, see our [SharePoint migration services](/services/sharepoint-migration).

OneDrive Migration

OneDrive migration is conceptually simple (copy files from source user's OneDrive to target user's OneDrive) but operationally complex at scale:

• Pre-provision OneDrive sites in the target tenant for all migrating users
• Migrate content preserving folder structure, sharing links, and version history
• Plan for 1-3 GB/hour per user at scale (throttling limits)
• Communicate to users that sharing links will break and must be re-shared

Teams Migration

Teams migration is the most painful workload because Teams data is distributed across multiple services:

• Team structure: Recreate teams and channels in the target tenant
• Chat history: Use third-party tools (AvePoint, BitTitan) to migrate chat history. Native Microsoft tools do not migrate chat.
• Files: Teams files are stored in SharePoint — migrate as part of SharePoint workload
• Apps and tabs: Reinstall and reconfigure apps, tabs, and connectors in each team
• Policies: Recreate messaging policies, meeting policies, and app permission policies

---

Phase 4: Cutover and Decommission (Weeks 18-24)

Cutover Planning

The cutover weekend is when the source tenant's primary domains are moved to the target tenant and all remaining users are migrated. This is the highest-risk event in the project.

Cutover checklist:

• Confirm all workload migrations are complete (zero items remaining)
• Verify mail flow between tenants is functioning correctly
• Test domain removal in a lab environment with the same domain structure
• Schedule cutover during a low-activity period (holiday weekend preferred)
• Staff a 24/7 command center for the cutover weekend
• Prepare rollback procedures for every cutover step
• Pre-communicate the cutover to all users with detailed instructions

Cutover sequence:

• Final delta sync of all workloads (capture changes since last migration pass)
• Set source tenant to read-only mode (disable user modifications)
• Remove primary domain from source tenant
• Add primary domain to target tenant and verify DNS
• Update UPNs for all migrated users to use the primary domain
• Validate mail flow, authentication, and application access
• Send "all clear" communication to users

Source Tenant Decommission

After cutover verification:

• Maintain source tenant for 90 days as a safety net
• Remove licenses from source tenant users (stop billing)
• Export any remaining data (compliance, audit logs, litigation hold content)
• Document the decommission process for audit trails
• Cancel or transfer source tenant subscriptions
• Delete the source tenant after the 90-day retention period

---

Common Pitfalls and How to Avoid Them

1. Underestimating Timeline

Every tenant-to-tenant migration we have seen attempted in under 4 months has failed or required significant scope reduction. Plan for 6-9 months for a 5,000-user migration and 9-12 months for larger organizations.

2. Ignoring Power Platform

Flows, apps, and environments in Power Platform often have hidden dependencies on SharePoint lists, Exchange connectors, and custom connectors that break during migration. Inventory Power Platform assets early.

3. License Mismatches

Source and target tenants may have different Microsoft 365 SKUs. E3 users in the source cannot be migrated to an E1 target without feature loss. Resolve licensing before migration.

4. Third-Party Application Dependencies

SaaS applications that authenticate via Azure AD in the source tenant must be reconfigured in the target tenant. This includes SSO configurations, SCIM provisioning, and API permissions.

5. No Coexistence Period

Cutting over without a coexistence period disrupts business operations. Users need time to adjust to the new tenant while maintaining access to source tenant resources.

For tenant-to-tenant migration consulting, our [SharePoint migration team](/services/sharepoint-migration) has deep experience with M&A migrations. [Contact us](/contact) for a scoping assessment.

---

Frequently Asked Questions

How long does a tenant-to-tenant migration take?

Plan for 6-12 months depending on user count and complexity. A 5,000-user migration with Exchange, SharePoint, Teams, and OneDrive typically takes 6-9 months from assessment to decommission. Organizations over 20,000 users should plan for 9-12 months.

What is the cost of a tenant-to-tenant migration?

Expect $30-$80 per user for tooling and $50-$150 per user for consulting services. A 10,000-user migration ranges from $800K to $2.3M all-in, including tooling, consulting, project management, and change management. The cost increases significantly with custom solutions and complex compliance requirements.

Can I do a tenant-to-tenant migration with native Microsoft tools only?

Partially. Microsoft provides native cross-tenant mailbox migration and cross-tenant sync for identities. However, SharePoint, OneDrive, Teams chat, and Power Platform require third-party tools for migration. You will need at least one third-party migration tool for a complete tenant-to-tenant migration.

What happens to Teams chat history during migration?

Teams chat history does not migrate natively. Third-party tools like AvePoint and BitTitan can migrate chat history, but the migrated content appears as imported messages rather than native chat. Some organizations choose to archive source tenant chat history rather than migrating it.

How do I handle conditional access policies during migration?

Conditional access policies must be recreated in the target tenant. During the coexistence period, configure both tenants to trust the other's authentication. After migration, consolidate policies in the target tenant and remove source tenant trust. Test conditional access thoroughly with pilot users before broad migration.