Microsoft’s native cross-tenant migration capabilities have become more practical, but they are not a complete answer for every Microsoft 365 tenant-to-tenant migration.
In 2026, Migration Orchestrator and related Microsoft 365 migration tools can move important user data, including Exchange Online mailboxes, OneDrive content, and selected Teams data. However, shared collaboration workloads, identity dependencies, devices, compliance requirements, permissions, and third-party applications still require separate planning and, in many cases, specialist tooling.
The correct question is not whether native tooling works. The correct question is where it fits within your migration architecture.
What Is Microsoft 365 Tenant-to-Tenant Migration?
A Microsoft 365 tenant-to-tenant migration moves users, data, applications, configurations, and associated services from one Microsoft 365 tenant to another.
The scenario commonly arises during:
- Mergers and acquisitions
- Divestitures and carve-outs
- Corporate rebranding
- Tenant consolidation
- Business separation
- Microsoft 365 modernization
- Changes to organizational ownership or governance
A tenant-to-tenant migration is more than a mailbox move. It can involve Microsoft Entra ID, domains, identities, Exchange Online, OneDrive, SharePoint, Teams, Power Platform, Intune, security controls, compliance policies, and integrated applications.
Microsoft provides useful native capabilities for specific workloads. A complete migration strategy must account for the areas those capabilities do not cover.
What Microsoft Migration Orchestrator Handles
Microsoft’s Migration Orchestrator documentation describes a batch-based approach for moving user-scoped Microsoft 365 data across tenants.
The principal capabilities include:
- Exchange Online mailbox migration
- OneDrive for Business migration
- Selected Teams chats and meetings
- Validation and migration batches
- Cross-Tenant User Data Migration licensing
- Identity mapping and target-user preparation
The tooling is designed primarily for user data. It does not create a complete target environment, migrate every directory object, or reproduce every application dependency.
Migration Orchestrator remains subject to feature availability, preview limitations, batch requirements, and Microsoft service changes. Organizations should validate current capabilities before committing to a production design.
Exchange Online Mailboxes
Exchange Online mailbox migration is one of the most established native capabilities.
Microsoft supports cross-tenant mailbox moves using Exchange Online PowerShell and migration batches. The process can move user-visible mailbox content such as:
- Contacts
- Calendars
- Tasks
- Notes
- Certain recoverable items
The target user must be prepared correctly, typically as a MailUser, with required values such as the ExchangeGUID, archive GUID where applicable, LegacyExchangeDN, X500 addresses, and target routing information.
The official cross-tenant mailbox migration guidance also identifies important constraints. Mailboxes on hold may be blocked from migration, mailbox permissions may require remediation, and the source mailbox is no longer available in the source tenant after a successful move.
Native mailbox migration is therefore valuable, but it still requires identity preparation, mail-flow design, domain planning, compliance review, and post-migration support.
OneDrive and Selected SharePoint Content
OneDrive for Business is supported as a user-scoped workload. This makes it suitable for moving personal files associated with migrating users, provided that identity mapping and licensing prerequisites are satisfied.
SharePoint requires more careful qualification.
Microsoft provides native cross-tenant SharePoint migration capabilities for certain site and content scenarios, generally using separate SharePoint Online PowerShell commands, cross-tenant relationships, and migration batches. However, Migration Orchestrator should not be treated as a universal SharePoint migration engine.
Complex SharePoint environments may include:
- Team sites
- Microsoft 365 Groups
- Channel sites
- Hub sites
- Custom permissions
- External sharing
- Workflows
- SharePoint Framework solutions
- Retention labels
- Sensitivity labels
- Custom metadata
- Embedded applications
Native tools may move specific SharePoint content, but they do not automatically resolve every site architecture, permission model, sharing link, workflow, or application dependency.
Teams Coverage Is Not Complete
Microsoft’s current native orchestration capabilities can address selected Teams chats and meetings. That does not mean a complete Teams environment is migrated.
Organizations should separately assess:
- Teams channels
- Channel conversations
- Files stored in SharePoint team sites
- Team and Microsoft 365 Group membership
- Meeting URLs
- Applications and tabs
- Bots and connectors
- Teams policies
- Voice and calling configurations
Microsoft documentation notes that migrated Teams meetings may retain URLs that are no longer valid in the target tenant, requiring meetings to be removed and recreated. Teams chat content also requires careful validation because mailbox folder content and Teams user experiences do not always align.
For environments with extensive collaboration, Teams should be treated as a distinct workstream rather than a secondary feature of mailbox migration.
What Native Tooling Still Does Not Cover
A reliable Microsoft 365 tenant-to-tenant migration plan must identify unsupported or partially supported areas before licensing and scheduling decisions are finalized.
Power Platform
Migration Orchestrator does not provide a complete cross-tenant migration for:
- Power Apps
- Power Automate flows
- Dataverse environments
- Custom connectors
- Connection references
- Environment variables
These workloads require export and import processes, dependency analysis, security review, and application testing. Flows may contain connections, service accounts, URLs, security groups, or custom APIs that do not transfer automatically.
Intune and Device Enrollment
Intune policies, profiles, compliance settings, certificates, application assignments, and device registrations require separate execution.
A user can be successfully migrated while the associated Windows, mobile, or managed device remains connected to the source tenant. Device enrollment, Microsoft Entra join, Windows Autopilot, conditional access, and endpoint security must be sequenced as a dedicated workstream.
Compliance, Holds, and eDiscovery
Compliance data does not simply follow a mailbox between tenants.
The migration assessment should identify:
- Litigation holds
- Retention policies
- Retention labels
- eDiscovery cases
- Communication compliance
- Information barriers
- Audit requirements
- Customer Key or encryption dependencies
- Regulatory records
A mailbox on hold may block migration. After migration, eDiscovery searches must generally be performed in the target tenant unless a controlled source copy or export has been retained.
Permissions, Sharing Links, and Custom Attributes
Permissions frequently depend on source tenant object identifiers. SharePoint permissions, OneDrive sharing links, mailbox delegates, group memberships, and application role assignments may require remapping.
Custom attributes, proxy addresses, directory extensions, Exchange permissions, and organizational metadata also require validation. A successful data transfer does not prove that the original access model has been reproduced.
Entra Applications and Third-Party Integrations
Microsoft Entra app registrations, enterprise applications, service principals, certificates, secrets, API permissions, and consent relationships are not automatically recreated as part of a standard user-data migration.
Third-party applications may depend on:
- Tenant IDs
- Object IDs
- App registrations
- OAuth consent
- Graph permissions
- SAML claims
- SCIM provisioning
- Email addresses
- SharePoint URLs
- Security groups
These dependencies should be inventoried during discovery and tested in the target tenant before cutover.
Why Hybrid Toolchains Are Often Required
Native Microsoft tooling can be an important component of a migration without being the only component.
A hybrid toolchain may combine:
- Migration Orchestrator for supported user-scoped workloads
- Exchange Online native migration batches
- Native SharePoint migration capabilities
- Quest On Demand Migration for broader workload, identity, device, and coexistence requirements
- Coherence proprietary tools and custom add-ons for edge cases, automation, validation, and integration with platforms such as Quest On Demand Migration
Quest’s platform supports broader migration scenarios involving identities, devices, SharePoint, Teams, Groups, Power BI, and coexistence. The correct toolset depends on scope, risk, data volume, timeline, and the required level of transformation.
A Controlled Migration Sequence
A proven migration methodology normally includes the following phases:
- Discovery and architecture: Inventory users, data, applications, domains, devices, permissions, compliance, and dependencies.
- Licensing and readiness: Confirm eligible Microsoft 365 plans, CTUDM licensing, domain ownership, target objects, and administrative access.
- Proof of concept: Validate mailbox, OneDrive, SharePoint, Teams, device, application, and compliance scenarios with representative users.
- Pilot wave: Migrate a controlled group and measure data integrity, client behavior, mail flow, access, and user support requirements.
- Coexistence: Maintain routing, free/busy, collaboration, address translation, and operational support while source and target environments operate together.
- Cutover: Execute migration batches, update identities and domains, complete Day One rebranding, and provide user communications.
- Validation and rollback readiness: Confirm migration results, maintain documented recovery procedures, and resolve exceptions before expanding the next wave.
- Knowledge transfer: Train internal teams on the target environment, support processes, governance, and remaining remediation.
Day One Rebranding Requires Separate Planning
A migration may be technically successful while users still experience the old organization through email addresses, sign-in prompts, meeting invitations, device names, application branding, or Outlook profiles.
Day One rebranding can include:
- New primary SMTP addresses
- Updated user principal names
- New tenant branding
- Outlook profile recreation
- Updated signatures
- New Teams meeting behavior
- Revised login instructions
- Updated mobile and device enrollment
- Revised application links and support contacts
Domain ownership is a particular constraint because a custom domain generally cannot be active in both tenants simultaneously. Domain release, verification, routing, and cutover sequencing must therefore be designed in advance.
How Coherence Supports Tenant-to-Tenant Migration
Coherence has delivered complex migration services since 2002, with consultants recording more than 10,000 hours of specialized migration experience.
Our team supports Microsoft 365 tenant-to-tenant migration, Active Directory and Entra ID migration, email migration, data migration, application dependency analysis, and M&A or divestiture programs. We use discovery, architecture, proof-of-concept testing, structured waves, project management, proprietary tooling, and knowledge transfer to reduce disruption and improve control.
Coherence has supported organizations including Microsoft, Google, American Express, WarnerMedia, Chevron, and the U.S. Air Force.
Review our Microsoft 365 tenant migration services and Office 365 migration guidance for related planning considerations.
Frequently Asked Questions
Is Microsoft Migration Orchestrator enough for a complete tenant-to-tenant migration?
No. Migration Orchestrator can handle important user-scoped workloads, but it does not replace discovery, identity preparation, application analysis, device migration, compliance planning, SharePoint architecture review, or user support. A complete migration normally requires native tools, specialist tooling, and structured project governance.
What is CTUDM licensing?
Cross-Tenant User Data Migration licensing is a one-time, per-user add-on used for supported cross-tenant data moves, particularly Exchange Online mailboxes and OneDrive. Eligibility and licensing terms can vary by Microsoft 365 plan, so procurement teams should verify current requirements in Microsoft Product Terms before migration.
Can Microsoft 365 Groups and Teams channels be migrated natively?
Not as a complete, automatic workload through the standard user-data orchestration process. Teams chats and meetings may have native coverage, while channels, team files, group structures, applications, permissions, and meeting links require separate assessment and tooling.
Can compliance-held mailboxes be migrated?
A mailbox on hold may be blocked from native cross-tenant migration. The organization must first assess legal, regulatory, retention, and eDiscovery requirements, then determine whether remediation, preservation, export, or an alternative migration approach is appropriate.
When should office 365 migration consultants be involved?
Office 365 migration consultants should be involved before tool selection and licensing. Early assessment identifies workload scope, domain constraints, identity dependencies, application integrations, device requirements, compliance risks, sequencing, and rollback requirements, allowing the migration estimate and target architecture to reflect the actual environment.
Plan the Migration Around the Gaps
Microsoft’s native capabilities can reduce complexity and cost when applied to the right workloads. They should not be treated as proof that every dependency will transfer automatically.
The responsible approach is to assess the environment, validate native coverage through a pilot or PoC, identify unsupported workloads, and design a hybrid migration plan where required. If you are planning a Microsoft 365 tenant to tenant migration, speak with the Coherence team about your users, workloads, timeline, licensing requirements, and business continuity objectives before selecting a final migration approach.
