Short answer: a Microsoft 365 tenant-to-tenant migration is a coordinated identity, data, domain, security, compliance, and operating-model change. It is not one copy operation. Exchange Online, OneDrive, SharePoint, Teams, Microsoft Entra ID, custom domains, retention controls, applications, devices, and integrations have different prerequisites and transfer behavior.
Start by defining the business scenario and the exact source-to-target scope. Then map identities, classify workloads, select a supported migration path for each workload, build coexistence and rollback plans, and validate a representative pilot before scheduling production waves. Do not assume that moving a user account also moves every workload, permission, policy, application connection, or shared resource.
How this Microsoft 365 migration guide was prepared
Reviewed: August 18, 2026. This guide uses current Microsoft documentation for tenant-to-tenant planning, Migration Orchestrator, individual workload moves, Microsoft Entra cross-tenant controls, domain removal, and Microsoft Purview holds. It does not promise a timeline, prescribe a universal user threshold, or treat a feature as supported without checking the current tenant, cloud, license, and workload prerequisites.
- Source policy: technical capability and prerequisite statements link to Microsoft documentation.
- Scope rule: create a separate decision for every workload, shared resource, identity dependency, compliance control, and integration.
- Freshness rule: verify licensing, preview status, supported clouds, known issues, limits, and required PowerShell modules immediately before execution.
- Validation rule: use prevalidation, a representative pilot, acceptance tests, exception logs, and a tested rollback path.
Choose the migration approach by workload
Microsoft’s tenant-to-tenant planning guide describes three paths. Migration Orchestrator coordinates supported workloads in batches. Individual cross-tenant tools provide workload-level control. Partner or third-party tooling may be needed when the required scope is outside Microsoft’s native capabilities or the internal team cannot operate the project safely.
| Approach | Use it when | Boundary to verify |
|---|---|---|
| Migration Orchestrator | Coordinating supported mailbox, OneDrive, Teams chat, and Teams meeting content for mapped users. | It moves in-scope content, not identities, Teams channels, or SharePoint sites. |
| Individual workload tools | Moving Exchange mailboxes, OneDrive accounts, or SharePoint sites with separate sequencing. | Each tool has different target-state, licensing, mapping, and retry constraints. |
| Partner or third-party path | Handling unsupported objects, specialized coexistence, transformation, or operational capacity gaps. | Require a written supported-item matrix, exclusions, security model, retry behavior, and validation evidence. |
The current Migration Orchestrator overview lists Exchange mailboxes, OneDrive, Teams chats, and Teams meetings as supported batch workloads. It also states that identities, Teams and channel shared data, and SharePoint sites are not moved by that orchestrated path. Treat those boundaries as design inputs, not details to discover during cutover.
Build a discovery inventory before selecting tools
Inventory the source and target tenants, then classify every item as migrate, recreate, reconfigure, archive, retain temporarily, or retire. Rivell’s cloud migration checklist provides a broader dependency framework. For Microsoft 365, the minimum discovery set is:
| Area | Evidence to capture | Acceptance question |
|---|---|---|
| Identities | Users, guests, groups, roles, UPNs, immutable IDs, attributes, authentication methods. | Does every source principal have an approved target outcome? |
| Domains and DNS | Verified domains, aliases, MX, Autodiscover, SPF, DKIM, DMARC, SIP, application records. | Can every dependency be removed, changed, tested, and restored? |
| Exchange Online | Mailbox types, sizes, archives, delegates, forwarding, transport rules, holds. | What moves natively, what must be recreated, and what is blocked? |
| OneDrive | Owners, sizes, permissions, sharing, retention, encryption, target-site state. | Are target accounts prepared without conflicting sites? |
| SharePoint | Sites, groups, permissions, sharing, workflows, customizations, storage. | Are target sites, groups, and unsupported customizations accounted for? |
| Teams | Teams, channels, chats, meetings, apps, phone numbers, policies, recordings. | Which content is in scope for the selected Microsoft path? |
| Compliance | Holds, cases, retention, labels, audit needs, records, data residency. | Can preservation be proved before and after each move? |
| Applications | Enterprise apps, app registrations, secrets, certificates, service principals, consent. | Who will reconfigure and test every tenant-bound integration? |
| Devices and management | Enrollment, compliance, configuration, security baselines, certificates, deployment tooling. | What user and support sequence moves devices to target management? |
| Power Platform and other services | Flows, apps, connections, environments, Planner, Forms, Power BI, Stream, Viva. | Is there a verified migration or rebuild path for each object? |
Resolve identity and access before moving content
Microsoft states that Orchestrator moves content, not identities. Source and target user objects must exist and be mapped correctly. The Orchestrator planning prerequisites require identity mapping before migration and warn that prematurely provisioned target mailboxes or OneDrive sites can cause failures. Follow the current preparation sequence for the selected tool rather than applying a generic licensing order.
Decide whether each user keeps or changes UPN, SMTP address, display name, group membership, and authentication method. Map guests and groups needed for content permissions. Document administrator accounts that do not depend on the transferring domain. Rivell’s identity and access management guide can help structure owners, access reviews, and lifecycle controls.
Cross-tenant migration and cross-tenant collaboration are separate capabilities. Microsoft Entra cross-tenant access settings control inbound and outbound B2B collaboration and trust behavior. Cross-tenant synchronization can provision and maintain B2B collaboration users and groups, but it does not replace the content-migration plan.
Plan each Microsoft 365 workload separately
Exchange Online
Microsoft’s cross-tenant mailbox migration documentation uses target-tenant migration batches and requires correctly prepared MailUser objects and attributes. Microsoft also states that mailboxes on hold are blocked from this native move and that only listed user-visible mailbox content is migrated. Inventory archives, shared and resource mailboxes, delegates, Send As and Full Access permissions, transport rules, connectors, journaling, and coexistence routing as distinct work items.
OneDrive and SharePoint
The cross-tenant OneDrive process is a move with source-to-target relationships and specific target-state prerequisites. Microsoft notes that incremental and delta passes are not available for that native move. The separate cross-tenant SharePoint process has its own site, group, target, and licensing requirements. Do not treat OneDrive and SharePoint as one undifferentiated file copy.
Inventory externally shared content, guests, permissions, site templates, workflows, apps, and target collisions. Rivell’s SharePoint external sharing guide explains the governance questions that should survive the move.
Teams and connected services
Orchestrator currently supports in-scope Teams chats and meetings when its prerequisites are met, but its overview excludes Teams and channel shared data. A Team also depends on a Microsoft 365 group, an Exchange mailbox, SharePoint storage, identities, policies, apps, and sometimes Teams Phone. Create separate acceptance tests for chat visibility, meeting ownership, channels, files, membership, guest access, recordings, applications, phone numbers, emergency calling, and policy assignment.
Planner, Forms, Power BI, Power Platform, Stream, Viva, Intune, app registrations, service principals, and third-party integrations need explicit owner and tool decisions. If Microsoft documentation or the chosen provider does not confirm an object is supported, classify it as unresolved until a pilot proves the result.
Protect compliance and retention requirements
Do not remove a hold merely to make a migration batch pass without legal and compliance approval. Microsoft’s mailbox documentation says held mailboxes are blocked from the native cross-tenant mailbox move. The Microsoft Purview hold guidance also explains that holds do not continuously follow location identity changes. Inventory every eDiscovery case, hold, retention policy, label, mailbox, site, OneDrive location, and Teams-connected location. Define how preservation, chain of custody, access, and post-move verification will be demonstrated.
Rivell’s Microsoft 365 legal hold guide provides a workload-level preservation checklist. Keep compliance signoff separate from the technical migration approval.
Sequence domains, coexistence, pilot, and cutover
A custom domain cannot be attached to both tenants at the same time. Microsoft’s domain removal guidance requires the domain to stop being the default and to be removed from users, shared and resource mailboxes, contacts, groups, teams, distribution lists, and administrator sign-ins before removal. Build the dependency inventory first. Set DNS changes according to the actual hosting provider, current TTLs, mail-flow design, and rollback plan rather than assuming a fixed window.
For phased migrations, document source-to-target mail routing, free/busy, Teams federation or B2B collaboration, help-desk escalation, and the date each identity becomes authoritative in the target. Use Rivell’s business migration planning guide to connect technical waves to business dependencies. Use a pilot that represents large and small mailboxes, OneDrive and SharePoint variations, delegates, guests, mobile users, remote users, holds, applications, and device states. A pilot is successful only when the acceptance evidence matches the production scope.
Assign ownership and prove readiness
- Executive sponsor: approves scope, business priorities, outage tolerance, and unresolved risk.
- Identity owner: approves user mapping, domains, authentication, privileges, and lifecycle changes.
- Messaging owner: owns mailbox preparation, mail flow, coexistence, delegates, and acceptance.
- Collaboration owner: owns OneDrive, SharePoint, Teams, permissions, sharing, and exceptions.
- Compliance owner: approves hold, retention, audit, records, and data-residency handling.
- Application owner: reconfigures tenant-bound applications, secrets, certificates, consent, and connections.
- Support lead: prepares communications, support scripts, escalation, device steps, and user validation.
- Migration lead: controls batches, evidence, exceptions, go or no-go decisions, rollback, and closure.
Before each wave, require current backups or preservation evidence where applicable, passed prevalidation, an approved user list, known-exception ownership, tested communications, available support coverage, and a specific rollback trigger. After the wave, validate sign-in, mail flow, calendar, delegated access, files, permissions, Teams scope, applications, mobile access, device management, security controls, and compliance evidence. Record failures by user and workload rather than declaring a batch successful from its top-level status.
When to involve a Microsoft 365 migration partner
External help is useful when the project spans several workloads, lacks current tenant documentation, includes regulated data or holds, requires coexistence, has limited internal migration capacity, or needs application and device remediation. Rivell’s Microsoft 365 implementation consulting service can help define and operate that scope. Evaluate a provider on the written scope, exclusions, Microsoft capability mapping, identity sequence, security controls, pilot method, exception handling, evidence, rollback, support coverage, and ownership after cutover.
Rivell’s Microsoft 365 implementation consulting and Microsoft 365 support guide explain the service boundary. Broader planning resources include the advantages and tradeoffs of cloud migration, business migration planning guide, cloud provider evaluation guide, multi-cloud management guide, and managed IT services guide.
To scope the source tenant, target tenant, workloads, domain plan, compliance constraints, pilot, cutover, and post-migration support, contact Rivell. Review Rivell’s IT services for the broader support scope.
