Tenant-to-Tenant Migration: 2026 Best Practices for Microsoft 365

Microsoft 365 tenant-to-tenant migration is still a high-stakes project for mergers, acquisitions, divestitures, rebrands, and tenant consolidation. In 2026, success depends on more than moving mailboxes: you must plan identity, licensing, domains, Teams, SharePoint, compliance, devices, and user experience together.

What Is Tenant-to-Tenant Migration?

A Microsoft 365 tenant-to-tenant migration moves users, data, workloads, and configurations from one Microsoft 365 tenant to another. It is commonly required during mergers and acquisitions, divestitures, brand changes, domain consolidation, or rationalization of multiple tenants.

Unlike a basic email migration, a tenant move can affect Microsoft Entra ID identities, Exchange Online mailboxes, OneDrive, SharePoint, Teams, Microsoft 365 Groups, Planner, Power Platform, Microsoft Purview, Intune, Defender, third-party apps, DNS, licensing, and end-user device configuration. Treat it as a business transformation project, not only an IT copy operation.

Choose the Right Migration Approach

There is no single migration method that fits every tenant. In 2026, most projects use a combination of native Microsoft capabilities, third-party tooling, scripting, and carefully planned coexistence.

Common approaches include:

• Native Exchange Online cross-tenant mailbox migration for supported mailbox scenarios, using migration endpoints, organization relationships, and properly prepared target objects.
• Microsoft 365 cross-tenant user data migration options where available and appropriate for workloads such as OneDrive.
• Third-party migration platforms for broader SharePoint, Teams, OneDrive, Microsoft 365 Groups, permissions, reporting, and staged-wave requirements.
• PowerShell, Microsoft Graph, and workload-specific APIs for discovery, remediation, reporting, and automation.
• Coexistence or staged cutover models when users, domains, or workloads cannot all move at once.

The best approach depends on tenant size, identity model, domain requirements, coexistence needs, compliance obligations, data volume, Teams complexity, and licensing constraints.

Start with a Practical Discovery Checklist

Before moving data, complete a structured assessment. At minimum, document:

• Tenants, verified domains, accepted domains, DNS records, MX, SPF, DKIM, DMARC, and Autodiscover.
• Users, shared mailboxes, resource mailboxes, archive mailboxes, distribution groups, mail-enabled security groups, dynamic groups, and Microsoft 365 Groups.
• Microsoft Entra ID configuration, including hybrid identity, Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync, cross-tenant access settings, B2B users, conditional access, MFA methods, security groups, enterprise applications, app registrations, and SSO dependencies.
• Exchange Online mail flow rules, connectors, transport settings, retention policies, litigation hold, public folders, and journaling.
• SharePoint and OneDrive sites, storage, permissions, external sharing, sensitivity labels, retention labels, large libraries, sharing links, orphaned users, hub sites, and customizations.
• Teams, including channels, private channels, shared channels, tabs, apps, connectors, meeting recordings, calling configuration, and compliance records.
• Intune-managed devices, compliance policies, configuration profiles, enrollment methods, mobile app policies, and re-enrollment requirements.
• Microsoft Purview retention, eDiscovery, DLP, audit, sensitivity labels, data residency requirements, and legal hold obligations.
• Third-party SaaS, line-of-business apps, SMTP relay, backup tools, security tools, and integrations that depend on tenant IDs, app registrations, mail routing, or SSO.
• Licensing, subscription ownership, CSP/NCE terms, target-tenant license availability, and required overlap periods.

Plan Identity with Microsoft Entra ID First

Identity is the foundation of tenant migration. Poor identity planning can break access to email, files, Teams, apps, devices, and security controls.

Key planning items include:

• Decide whether users will be cloud-only, hybrid, or synchronized from Active Directory.
• Review Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync dependencies, including source anchors, immutable IDs, UPNs, proxy addresses, and object matching.
• Configure Microsoft Entra cross-tenant access settings and B2B collaboration where temporary coexistence is required.
• Recreate or migrate security groups, dynamic groups, administrative units, enterprise applications, app registrations, and SSO configurations as needed.
• Rebuild conditional access policies carefully, including exclusions, break-glass accounts, device compliance rules, location policies, and MFA requirements.
• Plan authentication method registration. Users may need to re-register MFA methods, passwordless sign-in, or device-based authentication in the target tenant.
• Assess Intune, Defender, and device compliance impacts before cutover.

Do Not Treat Licensing as an Afterthought

Licensing is a common source of delays in tenant-to-tenant migration. In CSP and New Commerce Experience (NCE) scenarios, subscriptions generally cannot simply be moved from one tenant to another. The target tenant normally needs its own subscriptions, and the commercial impact must be planned in advance.

Plan for:

• Target-tenant subscription procurement before migration waves begin.
• License overlap periods so source and target services can run during coexistence and validation.
• Service-plan parity so users do not lose features such as archive mailboxes, Teams Phone, Defender, Purview, Power BI, or Intune.
• NCE term, cancellation, renewal, and seat-reduction constraints.
• Temporary or trial licensing only when it is appropriate and compliant with Microsoft licensing terms.
• Automated license assignment through groups where possible.
• Decommission timing for source-tenant subscriptions after validation, retention, and legal requirements are satisfied.

Prepare Domains, DNS, and Mail Flow Carefully

Domain moves are often the most time-sensitive part of a migration. A domain cannot be added to the target tenant until blockers are removed from the source tenant, unless a specific coexistence or domain-sharing approach is supported and intentionally designed.

Before cutover:

• Identify all references to the domain in users, aliases, shared mailboxes, groups, contacts, resource mailboxes, Teams, applications, and mail-enabled objects.
• Review accepted domains, connectors, mail flow rules, DKIM, SPF, DMARC, SMTP relay, and third-party filtering services.
• Lower DNS TTL values ahead of the change window.
• Prepare MX, Autodiscover, TXT, CNAME, DKIM, and other required records for the target tenant.
• Decide how mail will route during coexistence, especially if users migrate in waves.
• Validate rollback options, communication paths, and emergency mail-routing procedures.

Domain cutover should be scheduled during a controlled window with support teams ready for Outlook, mobile, and authentication issues.

Understand Workload-by-Workload Limitations

Not every Microsoft 365 workload migrates the same way. A realistic scope prevents surprises.

• Exchange Online: Mailboxes, calendars, contacts, shared mailboxes, archive mailboxes, permissions, delegates, rules, public folders, and mail flow all need separate validation. Some permissions and client profiles may need reconfiguration.
• OneDrive: Files can be migrated, but sharing links, external sharing, permissions, version history, retention labels, and sync client behavior require careful testing.
• SharePoint: Libraries, lists, permissions, metadata, versions, site settings, hub associations, custom pages, large lists, external sharing, sensitivity labels, and retention labels must be assessed.
• Teams: Teams migration is more limited than many users expect. Channels and files are often manageable, but chats, private and shared channels, meeting history, meeting links, apps, tabs, connectors, Planner integration, recordings, and compliance records may have limitations depending on tools and source configuration.
• Microsoft 365 Groups: Group membership, mailbox content, files, permissions, and connected workloads need coordinated handling.
• Planner and To Do: Migration is often partial and may require third-party tooling or API-based methods.
• Forms, Stream, Viva, Power BI, and Power Platform: These workloads require separate discovery because ownership, environment IDs, connectors, flows, gateways, and permissions may not transfer cleanly.
• Intune: Devices usually cannot be assumed to remain managed without impact. Re-enrollment, compliance evaluation, app protection, and configuration profiles must be planned.
• Microsoft Defender and Microsoft Purview: Security, compliance, retention, eDiscovery, audit, DLP, and sensitivity-label configurations should be reviewed and recreated or redesigned as needed.
• Third-party apps: Backup, archiving, CRM, ERP, identity, email security, and workflow tools may depend on tenant-specific app registrations, OAuth consent, or SSO configuration.

Use Secure Partner Access and Delegated Administration

A migration partner may need temporary administrative access, but that access should follow modern security practices. Avoid broad, permanent access.

For CSP and partner-assisted projects, use Granular Delegated Admin Privileges (GDAP) where applicable, with least-privilege roles, MFA, named accounts, audit logging, and time-bound access. Privileged access should be approved, documented, monitored, and removed after the project. Break-glass accounts, conditional access exclusions, and emergency procedures should also be reviewed before cutover.

Migrate in Phases, Not in a Single Leap

A phased migration reduces risk and improves user support.

A typical sequence includes:

1. Discovery and remediation: Clean up identity, domains, mail-enabled objects, stale permissions, and unsupported configurations.
2. Pilot wave: Migrate a small group with different user profiles, devices, and workloads.
3. Validation: Confirm mail flow, calendars, Teams, OneDrive sync, SharePoint access, mobile devices, MFA, and app access.
4. Production waves: Migrate users by department, geography, risk level, or business dependency.
5. Domain cutover: Move the primary SMTP domain and DNS records when blockers are removed and support is ready.
6. Post-migration stabilization: Resolve client issues, permissions gaps, device compliance problems, and workload-specific defects.
7. Decommission: Remove stale partner access, retire source-tenant services only after data, retention, legal, and business requirements are met.

Plan the End-User Experience

Even a technically successful migration can feel disruptive if users are not prepared. Communicate what will change and when.

Users may need to:

• Recreate or repair Outlook profiles.
• Sign back into Microsoft 365 apps.
• Reconfigure mobile mail profiles.
• Reset OneDrive sync and resolve known folder backup changes.
• Clear Teams cache or sign into the new tenant.
• Use new Teams meeting links after cutover.
• Re-register MFA or passwordless authentication methods.
• Re-enroll devices in Intune or complete compliance checks.
• Reconnect third-party apps that use Microsoft 365 authentication.

Prepare help desk scripts, known-issue guides, executive support, and extended support coverage for cutover windows.

Protect Compliance, Retention, and Chain of Custody

Compliance should be designed into the migration plan from the beginning. Review Microsoft Purview requirements before data is moved.

Include:

• Retention policies and retention labels.
• eDiscovery cases, legal hold, litigation hold, and preservation requirements.
• Audit log availability and export requirements.
• DLP policies and sensitivity labels.
• Data residency and regulatory obligations such as GDPR, HIPAA, FINRA, or industry-specific rules where applicable.
• Chain-of-custody documentation for sensitive or regulated data.
• Validation that migrated data remains discoverable and protected in the target tenant.

Do not decommission the source tenant until legal, compliance, and business stakeholders confirm that required data and evidence have been preserved.

When to Bring in a Migration Partner

Many organizations can migrate small, simple workloads internally. A specialist partner becomes valuable when the project includes multiple domains, hybrid identity, regulated data, Teams and SharePoint complexity, CSP/NCE licensing questions, Intune-managed devices, coexistence, executive downtime sensitivity, or limited internal capacity.

IT Partner can assist with Microsoft 365 migration planning, Microsoft Entra ID readiness, SharePoint and Teams migration, CSP licensing strategy, Microsoft Purview compliance alignment, and post-migration stabilization.

2026 Tenant Migration FAQs

Can Microsoft native tools handle tenant-to-tenant migration?

Sometimes. Native capabilities are useful for supported Exchange Online and selected Microsoft 365 user-data scenarios, but many projects still require third-party tools, scripting, or workload-specific remediation for SharePoint, Teams, Planner, permissions, and reporting.

Can Teams chats be migrated?

Teams migration has limitations. Files and channel structures are often more straightforward than chats, private or shared channels, meeting history, tabs, apps, connectors, and compliance records. Confirm what your selected tool can and cannot migrate before committing to a scope.

Can Microsoft 365 licenses move from one tenant to another?

Generally, licenses are not simply transferred between tenants, especially in CSP/NCE scenarios. Plan target-tenant subscriptions, overlap periods, service-plan parity, renewal dates, and cancellation constraints.

Is downtime required?

Some disruption is usually expected during domain cutover, DNS changes, client reconfiguration, and authentication changes. Good planning can reduce the impact, but it should not be advertised as risk-free or invisible to users.

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

Small, simple migrations may complete quickly, while complex enterprise or regulated migrations can take weeks or months. Timeline depends on data volume, identity model, domain complexity, Teams and SharePoint scope, licensing, compliance requirements, and user support readiness.

Key takeaways

• Tenant-to-tenant migration in 2026 requires coordinated planning across identity, licensing, domains, workloads, compliance, devices, and users.
• Use current Microsoft Entra ID terminology and plan cross-tenant access, conditional access, MFA, hybrid identity, app registrations, and Intune impacts before cutover.
• CSP/NCE licensing must be planned early because subscriptions generally cannot be moved directly between tenants.
• Teams, SharePoint, OneDrive, Planner, Power Platform, Purview, and Intune each have migration limitations that should be validated during discovery and pilot waves.
• Secure partner access should use GDAP, least privilege, MFA, auditability, and cleanup after the migration.

Planning a Microsoft 365 tenant-to-tenant migration? IT Partner can help assess your environment, design the migration approach, plan CSP/NCE licensing, secure Microsoft Entra ID, and execute a phased migration with user-focused support. Start with our Microsoft 365 Migration service.