Table of Contents
Review my Tenant to Tenant Migration Plan
Tenant-to-tenant (T2T) migration is far more than a simple data transfer. It is a complete re-platforming process. Each Microsoft 365 tenant operates as an independent Microsoft Entra ID trust boundary. It has its own directory GUID, token issuer, storage namespace, and compliance and retention policies. Because of this isolation, no data is transferred directly at the platform level. Instead, mailbox items, files, and metadata are extracted, mapped to the correct identities, and recreated in the destination tenant, all while maintaining permissions, relationships, and user context.
This guide explains what actually happens during a T2T migration, why many migration solutions stop at copying mailboxes and files, and why complex workloads such as Microsoft Loop, Teams meetings, and Teams recordings present the greatest migration challenges. It also demonstrates how the MacSonik Tenant to Tenant Migration addresses these complexities with a purpose-built approach that ensures a reliable migration experience.
What's Actually Happening During a T2T Migration?
Directory Identity Re-provisioning
Every user, group, and mail-enabled object is tied to the source tenant's directory. During migration, a new object is created in the target directory and linked to its source object using a UPN/email soft match or an ImmutableID hard match. Cross-tenant object references are not supported.
Hybrid Sync Re-pointing
If the source is synced via Entra Connect or Cloud Sync, that relationship is tenant-specific. Sync has to be disabled on the source (with a documented propagation delay before accounts become cloud-editable) before a new sync relationship can be established against the target directory.
Storage Namespace Re-platforming
Mailboxes, OneDrive drives, and SharePoint sites are provisioned against the target tenant's storage namespace. Content is read from source storage and written into newly created target containers.
Collaboration-layer Correlation
This is the layer where most migration tools fall short. Loop components, Team meetings, channel videos, Mails and SharePoint lists are more than just files. They contain embedded references to the original sender's object ID, meeting or channel container, and the source tenant's storage location.
Domain Ownership Sequencing
A verified vanity domain can only be attached to one tenant at a time. Target accounts are provisioned on a staging domain, the domain is fully released from the source tenant, then re-verified on the target — a hard sequential dependency.
SSO Trust Reconfiguration
SAML relying-party trusts are tied to a tenant's issuer URI. During migration, every enterprise application using SSO must be updated to trust the target tenant's issuer URI; otherwise, authentication will fail after cutover.
Why Migrate a Tenant to Another Tenant?
Mergers and Acquisitions
Folding an acquired company's M365 environment into the parent tenant.
Divestitures and Spin-offs
Splitting a business unit into its own independent tenant.
Tenant Consolidation
Collapsing multiple tenants into one to reduce licensing and admin overhead.
Rebranding or Domain Restructuring
Moving tenant structure without disrupting the vanity domain end users see.
Planning Essentials Most Migration Plans Skip
Tooling decides how content moves; planning decides whether the migration succeeds. Enterprise T2T plans should lock down five things before the first byte is copied:
Licensing Readiness
A target mailbox or OneDrive site cannot be provisioned without an assigned license. Purchase and stage licenses before provisioning, and catch plan mismatches early. A 100 GB source archive will not fit a 50 GB target plan.
Pilot Batch First
Migrate 10–20 representative users end to end, including at least one Loop-heavy team, one shared mailbox, and one large OneDrive, and validate the results before scheduling production waves.
Batching and Coexistence
Large tenants move in waves, which means a coexistence window where some users have moved and others have not. Plan mail routing, GAL synchronization, and calendar free/busy visibility between the two populations for that period.
Rollback Criteria
The copy phase is non-destructive, so the source tenant remains intact and rollback simply means pausing the plan. Once the vanity domain is released, the return path becomes a reverse migration. Define that point of no return, and the go/no-go checkpoints before it, in writing.
Security and Compliance: What Must Be Verified
For enterprise environments, the migration itself is a security event. Four areas need explicit sign-off from the security and compliance teams:
- Access Model: the migration should run on admin-consented, application-level credentials with scoped permissions, never on stored end-user passwords. Content moves over TLS-encrypted Microsoft APIs, and the migration app's consent should be revoked in both tenants once validation completes.
- Retention, Holds, and eDiscovery Do Not Migrate: retention policies, litigation holds, and eDiscovery cases are tenant-scoped. Recreate policies in the target before cutover, and resolve or export active legal holds on the source. Decommissioning a source tenant while a hold is active is a compliance incident, not a cleanup step.
- Audit Continuity: source-tenant audit logs do not transfer. Export the unified audit log before decommissioning the source so the compliance trail survives the migration.
Comparing the Methods
| Capability | Manual Scripting | Microsoft Native Tools | MacSonik T2T Tool |
|---|---|---|---|
| Requires local Outlook profile | Partial | No | No |
| Identity/sync re-pointing | Manual | Manual | Automated |
| Loop content correlation | Not handled | Not handled | Handled; re-linked, not static |
| Teams meeting/join links | Not handled | Not handled | Meeting object recreated |
| Teams video/recordings | Not handled | Not handled | Migrated with re-permissioning |
| Throttling handling | None | Platform-managed | Backoff + checkpointing |
| Resumable on failure | No | Per-batch retry only | Yes |
| Domain cutover sequencing | Manual | Manual | Orchestrated |
| Metadata preservation | Inconsistent | Mailbox/file level only | Full: flags, categories, permissions, references |
| Extra per-user migration license | Not required | Required | Not required |
Frequently Asked Questions
Q1. Does the vanity domain get disrupted during the copy phase?
Ans. No, target accounts run on a staging domain while bulk content copy proceeds, so live mail flow on the source domain is untouched until cutover.
Q2. Why does directory sync take time to disable?
Ans. It's a tenant-wide backend operation with a documented propagation window before synced accounts become cloud-editable. Building that window into the schedule is safer than relying on faster, unsupported workarounds.
Q3. Is Team chat history included?
Ans. Not as live, working conversations. Some tools export chat history as static HTML archives, but that is preservation, not migration. Chat messages are bound to the sender's original identity object, and there is no supported way to re-hydrate them cross-tenant as functioning chats. This is a platform constraint, not a tooling one.
Q4. What about Loop components and Teams meetings specifically?
Ans. This is the layer where most tools fall short, because these aren't flat files — they carry live references back to the source tenant. A correlation-aware engine has to re-resolve those references against the newly created target objects, which is exactly the gap MacSonik is built to close.
Q5. Do users need licenses in the target tenant before migration?
Ans. Yes. Target mailboxes and OneDrive sites can only be provisioned against assigned licenses, so licenses must be purchased and assignable before the provisioning step. Unlike Microsoft's native cross-tenant migration, a third-party engine does not additionally require the per-user Cross-Tenant User Data Migration add-on license.
Q6. What happens if we need to roll back mid-migration?
Ans. The copy phase reads from the source without modifying it, so the source tenant stays fully operational and rollback before cutover simply means pausing the plan. The point of no return is the domain release: after that, going back means a reverse migration. That is why the go/no-go checkpoint belongs immediately before the cutover step.
Q7. Do retention policies, litigation holds, and eDiscovery cases migrate?
Ans. No. These are tenant-scoped configurations, and no migration tool can move them; they must be recreated in the target tenant before cutover. Content under an active legal hold should be exported or the hold resolved before the source tenant is decommissioned.
Conclusion
The hard part of a tenant-to-tenant migration was never the mailbox or file copy. It's the identity correlation, the domain and licensing sequencing, the compliance baseline, and the collaboration-layer references (Loop, Teams meetings, channel video) that most plans ignore or leave for the admin to patch manually. Closing that gap requires a correlation-aware engine that treats every object as a source-to-target pair rather than a flat file to copy.
The Tenant to Tenant Migration Tool is built on exactly this model, giving administrators a way to consolidate, split, or restructure M365 tenants in 2026 without losing Loop content, breaking Teams meeting links, or leaving video and recordings behind.
Was this article helpful?
