Microsoft 365 Tenant-to-Tenant Migration Guide for 2026

Mergers, acquisitions, divestitures, rebranding, and tenant consolidation projects often require moving identities, mail, files, Teams, devices, security settings, and compliance controls from one Microsoft 365 tenant to another. In 2026, tenant-to-tenant migration is more capable than it was a few years ago, but it is still not a simple copy operation. Success depends on discovery, identity mapping, coexistence planning, security review, licensing readiness, cutover timing, and post-migration support.

What is a Microsoft 365 tenant-to-tenant migration?

A Microsoft 365 tenant is a dedicated cloud environment that contains an organization’s identities, domains, licenses, workloads, security configuration, and business data. A tenant-to-tenant migration moves selected users, groups, workloads, settings, and data from a source Microsoft 365 tenant to a target Microsoft 365 tenant.

In a modern project, the scope may include Microsoft Entra ID identities, Exchange Online mailboxes, OneDrive accounts, SharePoint sites, Microsoft Teams, Microsoft Intune, Microsoft Purview, Microsoft Defender settings, Conditional Access policies, Microsoft Viva, Power Platform, app registrations, enterprise applications, and third-party integrations.

A tenant migration is also a business transition. It affects sign-in, email routing, device management, file sharing, compliance retention, external collaboration, and user experience.

When do organizations need tenant-to-tenant migration?

Common scenarios include mergers and acquisitions, divestitures, corporate restructuring, brand consolidation, regional separation, cloud governance cleanup, and migration from a legacy or poorly governed tenant into a new standard environment.

Tenant name and branding changes are a frequent driver, but they should be evaluated carefully. A full migration is not always required just because a name changes. Tenant display names can be changed. Custom domains can be added or removed if all dependencies are handled. SharePoint domain rename is available with limitations and planning requirements. Some tenants can add another .onmicrosoft.com domain and use it as a fallback domain. However, the tenant ID and many foundational identifiers do not change, and some original namespaces or historical references may remain. If the business requires a clean tenant boundary, new identity authority, new governance model, or full separation, a tenant-to-tenant migration may still be the right approach.

Tenant region or data residency changes also require careful analysis. Microsoft 365 tenant location is not simply based on the external IP address used at sign-up. It is tied to the organization’s sign-up and billing country, service availability, and Microsoft data residency rules. Depending on the requirement, Microsoft 365 Multi-Geo, Advanced Data Residency, or workload-specific data location controls may solve the issue without a full migration. If the business needs to move to a different tenant jurisdiction or separate data ownership, migration may be required.

Modern migration approaches in 2026

There is no single migration method that fits every tenant. Most projects use one or more of the following approaches:

Native Microsoft cross-tenant capabilities: Microsoft provides native options such as Exchange Online cross-tenant mailbox migration, OneDrive cross-tenant user data migration, Microsoft Entra cross-tenant access settings, cross-tenant synchronization, B2B collaboration, Teams shared channels, and multitenant organization capabilities. These features can reduce friction, but they do not automatically migrate every workload or every configuration.

Third-party migration tooling: Specialized migration platforms are often used for SharePoint, Teams, Planner, Forms, Power Platform, Viva Engage, permissions mapping, reporting, retry logic, and large-scale staged migrations. Tool choice should be based on the workloads, data volume, compliance needs, and acceptable downtime.

Coexistence and federation: Some organizations keep both tenants active during a transition period. Coexistence can include mail flow routing, free/busy, Teams collaboration, cross-tenant access, shared channels, external collaboration, identity synchronization, and staged workload moves.

Big-bang cutover: A cutover migration moves a defined population over a short window. This may work for smaller or simpler tenants but requires strong communication, DNS planning, support readiness, and rollback planning.

Staged or phased migration: Larger organizations usually migrate in waves by business unit, geography, brand, or workload. This reduces risk but increases coexistence complexity.

Hybrid approach: Many real projects combine native Microsoft features, third-party tools, temporary coexistence, and manual remediation for special workloads.

Workloads that may require migration

Exchange Online: Mailboxes, archives, shared mailboxes, distribution groups, mail-enabled security groups, Microsoft 365 Groups, resource mailboxes, contacts, mail flow rules, accepted domains, connectors, transport configuration, quarantine policies, DKIM, SPF, DMARC, Autodiscover, and mailbox permissions must be reviewed. Native cross-tenant mailbox migration can be used when prerequisites are met.

Microsoft Entra ID: Users, groups, administrative roles, guest accounts, cross-tenant access settings, cross-tenant synchronization, Conditional Access, MFA methods, authentication methods, enterprise applications, app registrations, service principals, certificates, secrets, consent grants, and privileged access must be inventoried. Microsoft Entra ID is the identity foundation of the migration, so source anchors, immutable IDs, UPNs, proxy addresses, and object matching are critical.

OneDrive: User files, permissions, sharing links, ownership, sync state, retention, and legal hold requirements must be evaluated. Microsoft provides cross-tenant OneDrive user data migration for supported scenarios, but sharing links, permissions, and user sync clients still need careful validation.

SharePoint Online: Sites, hubs, pages, document libraries, lists, metadata, permissions, sharing links, custom scripts, web parts, workflows, Power Automate connections, SharePoint Embedded dependencies, and Teams-connected sites may require tool-assisted migration and remediation.

Microsoft Teams: Teams, channels, private channels, shared channels, files, tabs, apps, meetings, policies, phone settings, call queues, auto attendants, and governance settings must be planned. Teams migrations often have limitations around chat history, meeting links, app tabs, Planner integration, and permissions. Users may need new meeting links and updated collaboration guidance.

Microsoft Intune and devices: Device compliance policies, configuration profiles, security baselines, app deployments, enrollment profiles, Autopilot records, certificates, scripts, filters, device groups, and Microsoft Entra joined devices require planning. Many device scenarios require re-enrollment, rejoin, or user action.

Microsoft Purview and compliance: Retention labels, retention policies, sensitivity labels, DLP policies, eDiscovery cases, audit data, communication compliance, insider risk settings, and records management configuration should be assessed before migration. Some historical compliance data or audit data may not move in the same way as user content.

Security workloads: Microsoft Defender for Office 365, Defender for Endpoint, Defender for Cloud Apps, Safe Links, Safe Attachments, anti-phishing policies, attack simulation settings, alerting, Secure Score recommendations, and security automation should be reviewed and rebuilt or migrated where supported.

Power Platform and business apps: Power Apps, Power Automate flows, Power BI dependencies, Dataverse environments, connectors, service accounts, approvals, and embedded app integrations need separate discovery. Ownership and connection references frequently require remediation.

Microsoft Viva, Loop, Planner, Forms, and Viva Engage: These workloads can contain business-critical collaboration data but often have migration constraints. Viva Engage communities, conversations, files, Planner plans, Forms responses, Loop components, and Viva experiences should be included in discovery and tested before committing to a migration method.

Third-party integrations: SaaS applications, SSO, SCIM provisioning, API permissions, webhooks, certificates, secrets, SMTP relay, backup tools, archiving tools, monitoring, HR systems, CRM systems, and line-of-business apps must be validated in the target tenant.

Discovery checklist before migration

A reliable project starts with detailed discovery. At minimum, review:

• Identity inventory: users, groups, guests, roles, admins, service accounts, privileged accounts, authentication methods, and source anchors.
• Domain dependencies: UPNs, proxy addresses, accepted domains, vanity domains, DNS records, Autodiscover, DKIM, SPF, DMARC, and third-party mail systems.
• Licensing: source and target subscriptions, workload prerequisites, migration tool licenses, add-ons, and Microsoft 365 New Commerce Experience commitments.
• Exchange Online: mailbox sizes, archives, shared mailboxes, public folders if present, permissions, litigation hold, retention, and mail flow.
• OneDrive and SharePoint: storage volume, site count, permissions, external sharing, sensitivity labels, retention, customizations, and large files.
• Teams: team count, channels, apps, meetings, Teams Phone, shared channels, guest access, and Teams-connected SharePoint sites.
• Devices and Intune: device join state, enrollment method, compliance posture, Autopilot, certificates, mobile devices, and app protection policies.
• Security and compliance: Conditional Access, MFA, Defender, Purview, DLP, audit, eDiscovery, labels, and retention requirements.
• Applications: Microsoft Entra app registrations, enterprise apps, consent, secrets, certificates, SSO, SCIM, and third-party integrations.
• Power Platform: environments, flows, apps, connectors, Dataverse, ownership, and service accounts.
• External collaboration: guest accounts, B2B relationships, sharing links, partner access, and cross-tenant access policies.

Recommended migration phases

1. Strategy and project planning: Define business drivers, success criteria, scope, migration waves, coexistence model, risk tolerance, legal requirements, and communication plan. Confirm whether native Microsoft features, third-party tools, or a hybrid approach will be used.

2. Source and target tenant assessment: Inventory identities, domains, licenses, workloads, security configuration, compliance controls, applications, data volume, and known limitations. Identify blockers before migration begins.

3. Identity design and mapping: Decide how users, groups, guests, mail addresses, UPNs, immutable IDs, source anchors, admin roles, and application identities will map to the target tenant. Plan how authentication, MFA, Conditional Access, and privileged access will work on day one.

4. Licensing and subscription readiness: Assign the correct licenses in the target tenant before users are migrated. Keep source tenant licensing active long enough to support coexistence, validation, and rollback. Under Microsoft’s New Commerce Experience, review term commitments, seat changes, cancellation windows, add-ons, and duplicate licensing costs during overlap.

5. Target tenant preparation: Configure domains, baseline security, Conditional Access, MFA, Defender, Purview, mail flow, SharePoint settings, Teams policies, Intune, administrative roles, service accounts, and application prerequisites.

6. Pilot migration: Migrate a small representative group that includes executives, standard users, mobile users, delegated mailbox users, Teams-heavy users, OneDrive-heavy users, and device-managed users. Validate access, mail flow, permissions, sharing, Teams, mobile, Outlook, OneDrive sync, and business applications.

7. Pre-stage and delta synchronization: For larger projects, pre-stage mailbox, OneDrive, SharePoint, and Teams data where supported. Run delta passes to reduce final cutover time and manage throttling.

8. Cutover: Move domains and users according to the approved runbook. Update MX, Autodiscover, SPF, DKIM, DMARC, accepted domains, connectors, application redirect URIs, SSO settings, and device enrollment instructions as needed. Monitor mail flow, sign-in, Teams, OneDrive, and security alerts.

9. Post-migration validation: Confirm that data, permissions, mail routing, security policies, compliance controls, applications, devices, and collaboration scenarios work as expected.

10. Stabilization and support: Provide help desk scripts, executive support, user communications, known issue tracking, and remediation for Outlook profiles, Teams cache, OneDrive sync, mobile devices, MFA registration, and external sharing.

Cutover planning: what can go wrong

The highest-risk point in most projects is the cutover window. Important considerations include domain removal constraints in the source tenant, duplicate proxy addresses, unresolved guest users, mailbox forwarding, mail-enabled groups, DNS TTL, Autodiscover behavior, third-party filtering, SMTP relay, DKIM key rotation, SPF record length, DMARC alignment, and hybrid mail flow.

User experience also needs planning. Outlook profiles may need to be recreated or repaired. Mobile mail profiles may need to be reconfigured. Teams users may need to sign out and back in, clear cache, or use new meeting links. OneDrive sync clients may need to be reset or redirected. Microsoft Authenticator or MFA methods may need re-registration depending on identity design. Microsoft Entra joined or Intune-managed devices may require rejoin, re-enrollment, or Autopilot remediation.

External collaboration is another common source of issues. OneDrive and SharePoint sharing links may break or require re-sharing. Guest accounts may need to be re-invited or synchronized differently. Teams shared channels and B2B collaboration policies must be validated in both tenants.

Known limitations and risks

Tenant-to-tenant migration is not a perfect clone. Some items may not migrate natively, may migrate with reduced fidelity, or may require manual remediation. Common limitations include Teams chat history, Teams meeting links, Planner tasks, Forms ownership and responses, Loop components, Viva Engage conversations, Power Automate connection references, Power Apps ownership, Power BI dependencies, app consent grants, enterprise application configuration, audit history, eDiscovery case history, retention state, sharing links, device trust, and user profile state.

Permissions must be remapped carefully because object IDs change between tenants. Application secrets and certificates must be rotated or recreated where appropriate. Conditional Access policies should not simply be copied without reviewing target tenant risk, break-glass accounts, locations, device compliance, and authentication strength requirements.

A rollback plan is essential. Some steps, such as domain moves, DNS changes, device re-enrollment, and user identity changes, can be disruptive to reverse.

Post-migration checklist

After cutover, validate both technical success and user productivity:

• Test inbound and outbound mail, calendar sharing, mailbox delegation, shared mailboxes, and distribution groups.
• Verify MX, Autodiscover, SPF, DKIM, DMARC, connectors, and mail security policies.
• Confirm Outlook profile behavior, mobile mail access, and mailbox archive access.
• Validate Teams sign-in, channels, meetings, files, apps, calling, and external collaboration.
• Confirm OneDrive sync, SharePoint permissions, external sharing, and critical business sites.
• Validate Microsoft Entra ID sign-in, MFA, Conditional Access, privileged roles, and break-glass accounts.
• Check Intune enrollment, compliance policies, app deployment, device certificates, and mobile application management.
• Confirm Defender, Purview, retention, DLP, sensitivity labels, eDiscovery, and audit requirements.
• Validate enterprise applications, SSO, SCIM provisioning, app registrations, secrets, certificates, and service accounts.
• Review Power Platform flows, apps, connectors, approvals, and Dataverse environments.
• Monitor help desk tickets, user sentiment, service health, security alerts, and migration tool reports.
• Decommission source tenant services only after legal, compliance, business, and technical owners approve.

How IT Partner can help

IT Partner helps organizations plan and execute Microsoft 365 tenant-to-tenant migrations with a practical focus on business continuity, security, compliance, and user experience. A typical engagement can include tenant assessment, migration strategy, workload discovery, identity mapping, pilot migration, migration tooling selection, coexistence configuration, cutover support, post-migration remediation, and source tenant decommissioning.

Because every tenant is different, the right first step is a scoped assessment. That assessment should identify workloads, data volume, licensing needs, compliance constraints, risks, dependencies, and the migration approach before the project timeline is committed.

Key takeaways

• Tenant-to-tenant migration is still essential for mergers, acquisitions, divestitures, consolidation, rebranding, and governance projects, but the scope in 2026 goes far beyond email.
• Use current terminology and architecture: Microsoft Entra ID, Microsoft Entra joined devices, Microsoft Viva Engage, Microsoft Purview, Microsoft Defender, and modern cross-tenant capabilities.
• A full migration is not always required for naming or data residency changes; evaluate tenant display name changes, domain changes, SharePoint domain rename, Multi-Geo, and Advanced Data Residency first.
• Native Microsoft capabilities can help with Exchange Online, OneDrive, cross-tenant access, cross-tenant synchronization, B2B collaboration, Teams shared channels, and multitenant organizations, but many workloads still require tooling and remediation.
• The most important success factors are discovery, identity mapping, licensing readiness, pilot testing, coexistence planning, DNS and mail flow preparation, user communication, and post-migration support.

Planning a Microsoft 365 tenant-to-tenant migration? IT Partner can assess your source and target tenants, identify risks, recommend the right migration approach, and help migrate Exchange Online, SharePoint, OneDrive, Teams, Microsoft Entra ID, Intune, security, and compliance workloads with a controlled cutover plan.