Microsoft Tenant-to-Tenant Migration: How to Move Seamlessly
Migrating Microsoft 365 from one tenant to another is a significant undertaking. There’s a lot to uncover before you start—and a lot that can go wrong.
Luckily, you can avoid the pitfalls and migrate smoothly with the right process in place.
Whether you work with a Microsoft solutions expert or do it in-house, here’s everything you need to know.
Key takeaways:
- Microsoft doesn’t provide native tools covering the full scope of a tenant-to-tenant migration.
- A tenant-to-tenant migration should cover all Microsoft solutions and systems, including Exchange Online mailboxes, OneDrive and SharePoint content, Teams, identity, and more.
- A Microsoft tenant-to-tenant migration typically runs 4–12 weeks end-to-end, with the exact timeline driven by the discovery process.
- Best practices for tenant-to-tenant migration include front-loading essential discovery and preparation tasks, even if they feel premature.
💡 Ready to plan your migration?
Let’s talk.
What is a Microsoft tenant-to-tenant migration?
A Microsoft tenant-to-tenant migration is the process of moving users, mailboxes, files, groups, and other Microsoft 365 workloads from one Microsoft Entra ID (formerly Azure AD) tenant to another. This type of migration is often driven by a merger, acquisition, divestiture, or corporate rebrand. In these scenarios, the migration is often just one component recommended in a full-scale M&A consulting engagement.
Microsoft doesn’t provide a native tool that moves everything, so most Microsoft customers and MSPs use third-party migration platforms (BitTitan, Quest, AvePoint) or Microsoft’s cross-tenant identity mapping and mailbox migration features. Regardless of the chosen tool, most organizations choose to migrate data in phases rather than in a single cutover.
What Microsoft systems are covered in a tenant-to-tenant migration?
A Microsoft tenant-to-tenant migration usually covers all relevant Microsoft systems as well as the processes required for a smooth transition. This includes things like:
- Exchange Online mailboxes
- OneDrive and SharePoint content
- Teams channels and chats
- Identity objects
- Planning around domain name transfer (a custom domain can only be verified in one tenant at a time)
- License procurement in the target tenant
- Coexistence during the cutover window so mail flow and free/busy calendar lookups keep working
- Device re-enrollment in Intune
How long does a Microsoft tenant-to-tenant migration take?
A Microsoft tenant-to-tenant migration typically runs 4–12 weeks end-to-end for a mid-market organization of 100–500 users, with 6–8 weeks being the most common landing spot. Smaller, single-workload moves can take as little as 2–3 weeks; large, multi-workload, or heavily regulated environments regularly stretch to 4–6 months.
Data volume is rarely the biggest driver of the timeline. Rather, factors like completeness of discovery, coexistence requirements, and coordination across the business tend to influence the timeline significantly.
Note that the phases below often overlap in practice. Production waves can run while discovery and app remediation continue in parallel. This means the overall duration isn’t simply the sum of the duration of each phase.
Phase | Typical duration | What happens |
Discovery & assessment | 1–2 weeks | Inventory tenants, workloads, licenses, shared mailboxes, app registrations, and device enrollment state |
Planning & design | 1–2 weeks | Migration approach, wave structure, coexistence design, domain cutover sequencing, rollback plan |
Environment prep | 1–2 weeks | Target tenant build-out, licensing procurement, security/conditional access baseline, tooling setup |
Coexistence setup | 3–5 days | Cross-tenant identity mapping, mail flow, free/busy, directory sync between tenants |
Pilot migration | 3–5 days | 10–25 representative users migrated and validated before production waves begin |
Production waves | 2–6 weeks | Bulk mailbox, OneDrive, SharePoint, and Teams migration in scheduled batches |
Domain cutover | 1–2 days | Domain removed from source, verified in target, MX and DNS repointed—usually over a weekend to avoid business downtime |
Post-migration & hypercare | 1–2 weeks | Device re-enrollment, app SSO reconfiguration, cleanup, elevated support coverage |
Can I keep my existing domain name when migrating from one Microsoft tenant to another?
Yes, you can keep your existing domain name, but not simultaneously in both tenants. Microsoft enforces global uniqueness on verified custom domains across all of Entra ID, so [yourcompany.com] must be fully released from the source tenant before it can be verified in the target.
This constraint creates the cutover window. There’s an unavoidable gap, usually measured in minutes to a couple of hours, when the domain belongs to neither tenant. Most organizations schedule it for a weekend or overnight. They also pre-stage every dependent object so the release-and-claim sequence runs back-to-back.
Process to retain your domain in a Microsoft tenant-to-tenant migration
- Inventory every object using the domain in the source tenant — user UPNs and proxy addresses, distribution and Microsoft 365 groups, shared and resource mailboxes, Teams voice numbers, app registrations, enterprise applications, and Exchange connectors. Anything still referencing the domain will block its removal.
- Pre-stage specific tenant users with the onmicrosoft.com domain (e.g. user@company.onmicrosoft.com) so accounts, licenses, and group memberships already exist and only need the UPN swapped after the domain lands.
- Migrate data ahead of the cutover — mailboxes, OneDrive, SharePoint, and Teams content should already be in the target tenant, seeded and delta-syncing, before the domain moves.
- Lower DNS TTLs on MX, autodiscover, SPF, DKIM, and DMARC records to 300 seconds at least 48 hours in advance, so propagation is fast when you repoint.
- Strip the domain from all source objects — rename UPNs and primary SMTP addresses back to onmicrosoft.com, remove proxy addresses, delete or rename groups, and clear the domain from any Teams or Exchange configuration.
- Remove the domain from the source tenant in the Microsoft 365 admin center. Microsoft will report any remaining dependencies if the removal fails; expect to iterate here, as it’s the most common point where a cutover stalls.
- Add and verify the domain in the target tenant using the TXT record Microsoft generates. Verification is usually quick, but you should allow for DNS propagation delay.
- Repoint DNS to the target tenant — MX, autodiscover, SPF, DKIM selectors, DMARC, and any Teams or Skype SRV records.
- Update UPNs and primary SMTP addresses in the target tenant to the newly verified domain, then confirm license and mail flow assignment on each account.
- Validate before releasing users — send and receive external mail both directions, test free/busy across the remaining coexistence boundary, confirm autodiscover resolves for Outlook clients, and verify SSO for apps that rely on the domain.
- Hold a rollback window — keep the source tenant intact and licensed for at least 30 days. Re-verifying the domain back in the source is possible but slow, so the practical rollback is mail routing, not a full reversal.
There’s one caveat to be aware of as you make your plans. If the domain is also used for federated SSO with third-party apps or as the identity domain for non-Microsoft services, those integrations need to be re-pointed at the new tenant ID separately. The domain moving doesn’t carry them.
What are the most common failure points in Microsoft tenant-to-tenant migrations?
Most tenant-to-tenant migrations fail for organizational reasons rather than technical ones. The mailbox and file data usually transfer just fine. What breaks is the surrounding environment—for example, the shared mailbox that nobody documented, the line-of-business app with a hard-coded tenant ID, or the 400 laptops that need re-enrollment on Monday morning.
Migration failures often occur at the seams between workloads. They also occur through miscommunication between IT and the business. Companies should engage in comprehensive discovery depth and communication planning to mitigate both types of issues.
Failure point | Why it happens | Solution |
Incomplete discovery | Shared mailboxes, service accounts, distribution lists, and app registrations accumulate over years in an undocumented state | Run automated tenant discovery (Graph/PowerShell exports plus migration tool scans) rather than relying on IT recollection; validate against actual mail flow logs |
Domain removal blocked | Lingering objects still reference the domain, so Microsoft rejects the removal mid-cutover | Script a pre-cutover dependency check and remediate UPNs, proxy addresses, and group aliases days ahead; rehearse the removal in a lower-stakes subdomain first |
Target licensing gaps | Licenses procured for headcount alone—not for shared mailboxes, resource accounts, or add-ons like Teams Phone and Defender—can cause this issue | Build the license map from the discovery inventory, not the HR roster; purchase with 10–15% buffer and verify assignment before each wave |
Intune device re-enrollment | Devices remain joined to the source tenant and lose management after cutover | Plan device migration as its own workstream—either re-enroll in waves with user self-service instructions, or use Autopilot/Windows re-provisioning for high-risk fleets |
Conditional access and MFA friction | Target tenant policies differ, and users must re-register MFA methods on day one | Replicate CA policies in report-only mode first, stage MFA re-registration during a temporary trusted-location grace window, and staff the help desk heavily for 72 hours |
App SSO and hard-coded tenant IDs | Third-party SaaS apps authenticate against the source tenant ID, which the domain move does not carry | Inventory enterprise applications early, open vendor tickets weeks ahead, and cut over app-by-app rather than assuming they follow the domain |
Teams data loss | Private channel history, chat history, and some Teams metadata may not migrate natively or completely | Set expectations with the business in writing about what won’t move; export critical channel content separately and archive the source tenant before decommissioning |
Coexistence not configured | Users in the two tenants can’t see free/busy or resolve each other in the GAL during a multi-week wave migration | Stand up cross-tenant identity mapping, mail flow connectors, and organization relationships before wave one, not after complaints start |
Permissions don’t follow the data | SharePoint and OneDrive permissions, mailbox delegates, and Send As rights break because identity mappings are incomplete | Build a complete source-to-target identity map before migrating content; run permission validation on the pilot group and fix the map before production waves |
Compliance and retention gaps | Litigation holds, retention policies, and audit logs stay in the source tenant | Engage legal/compliance during planning; keep the source tenant licensed through the retention obligation rather than decommissioning on schedule |
Poor user communication | Users hit password prompts, missing Outlook profiles, and re-authentication with no warning | Send staged comms at T-14, T-2, and cutover day with screenshots of exactly what users will see; run a pilot group as internal champions |
Big-bang cutover on a large tenant | One weekend, no room to absorb problems, help desk overwhelmed on Monday morning | Run the migration in waves for anything above ~100 users, sequence low-risk departments first, and hold a hypercare window with elevated support staffing |
What are the best practices for Microsoft tenant-to-tenant migration?
Best practices for tenant-to-tenant migration mostly focus on front-loading work that may feel premature. The teams that cut over cleanly spend a disproportionate share of the timeline on discovery, identity mapping, and communication before they move a single mailbox. They also define what “done” means before they start, including what they’ve explicitly agreed not to migrate.
Here are crucial best practices for every phase of a Microsoft tenant-to-tenant migration.
Planning and discovery
- Run automated discovery, not interviews. Export tenant inventory via Graph and PowerShell alongside your migration tool’s scan. IT recollection reliably misses shared mailboxes, service accounts, and stale app registrations.
- Build the identity map first. A complete source-to-target user and group mapping is the single artifact everything else depends on. Permissions, delegates, and content ownership all break without it.
- Define scope exclusions in writing. Agree with the business up front on what won’t move (private channel history, Power Platform environments, certain compliance artifacts) and get it acknowledged before the project starts, not during hypercare.
- Set a data cleanup window before migration. Archive or delete dormant mailboxes, stale OneDrive accounts, and unused groups. Migrating dirty data costs licensing and time. It also introduces risk.
- Assign a business owner per department. This is someone outside IT who can answer “does this mailbox still matter” and speak for their users during wave scheduling.
Design and preparation
- Design coexistence before wave one. Cross-tenant identity mapping, mail flow connectors, and Exchange organization relationships need to be live before the first user moves, not added after complaints.
- Replicate security baseline in report-only mode. Stand up conditional access, MFA policies, and Defender configuration in the target tenant and run them in report-only for a week to catch policy conflicts without locking anyone out.
- Build licensing from the discovery inventory. Count shared mailboxes, resource accounts, and add-on SKUs, not headcount. Carry a 10–15% buffer.
- Treat devices as their own workstream. Intune re-enrollment has its own timeline, its own user impact, and its own rollback considerations. Sequencing it with mailbox waves is a common source of Monday-morning outages.
- Open vendor tickets early for app SSO. Third-party apps pointed at the source tenant ID need vendor-side changes with their own lead times—often weeks.
Execution
- Pilot with 10–25 representative users. Include a power user, an executive assistant with heavy delegate permissions, a shared-mailbox-dependent role, and someone on a non-standard device. Validate permissions and delegates specifically, not just mail delivery.
- Migrate in waves, sequenced by risk. Low-complexity departments first, executives and finance later once the process is proven. Anything above roughly 100 users should be migrated in waves.
- Pre-seed and delta-sync content. Bulk data should already be in the target tenant well before cutover, with only deltas moving during the window.
- Lower DNS TTLs 48 hours ahead. MX, autodiscover, SPF, DKIM, and DMARC at 300 seconds so propagation isn’t the bottleneck during the domain swap.
- Script the domain dependency check. Run it repeatedly in the days before cutover so removal doesn’t stall at the very moment when you can least afford it.
- Rehearse the cutover. Walk the release-and-claim sequence step by step with the team, including who does what and in what order, with a named decision-maker for go/no-go.
Communication and post-migration
- Communicate at T-14, T-2, and cutover day. Include screenshots of exactly what users will see, such as the password prompt, the Outlook profile rebuild, and the MFA re-registration screen.
- Provide fully staffed hypercare for 72 hours. Expect ticket volume to rise several multiples above baseline immediately after each wave, concentrated on authentication and Outlook profile issues.
- Validate before declaring completion. Bidirectional external mail flow, free/busy across the coexistence boundary, autodiscover resolution, SharePoint permissions on migrated sites, and app SSO should all be tested, not assumed.
- Keep the source tenant licensed for 30+ days. You may want to keep it longer if legal holds or retention obligations apply. Decommissioning on the original schedule is a decision that’s difficult to reverse.
- Document the target tenant as built. The configuration you land on is rarely the one you designed, and the next admin will need to know why.
How much does a Microsoft tenant-to-tenant migration cost?
For mid-market and enterprise organizations, a realistic all-in planning range is roughly $25,000 to $150,000. Single-workload moves generally fall at the low end of that range, while multi-workload M&A consolidations with Teams, Intune, and compliance requirements typically land closer to the high end. Most providers won’t quote a fixed price before a discovery and scoping engagement, which is itself a reasonable signal. A firm number offered before assessment usually means scope will move later, or the provider has limited experience migrating Microsoft environments.
Details of Microsoft tenant-to-tenant migration costs
You should budget for a Microsoft tenant-to-tenant migration in three buckets:
- Microsoft’s own licensing
- Migration tooling or services
- The overlap cost of running both tenants at once.
Cross-tenant migrations aren’t included in an existing Microsoft 365 subscription. Rather, they require a specific Cross Tenant User Data Migration license. This is a one-time per-user fee that covers both mailbox and OneDrive migration. Note that migrations fail outright if this isn’t in place.
On top of licensing, standalone migration services commonly run $40 to $80 per mailbox above a small flat fee for the first few. Meanwhile, M&A tenant consolidations tend to run two to three times a standard migration, depending on complexity.
The takeaway: Plan your Microsoft tenant-to-tenant migration for success
Microsoft tenant-to-tenant migrations are complex, but with the right discovery, planning, and implementation processes, they can go off without a hitch. Here at Corsica Technologies, we’ve helped 1,000+ companies move forward on their technology journeys. Contact us today, and let’s flawlessly migrate your Microsoft environment to your new tenant.
Related posts
With over a decade of experience in IT, Garrett Wiesenberg brings deep technical expertise and a strong commitment to strategic problem-solving. For the past four years, he has focused on architecting and delivering advanced solutions for managed clients, consistently aligning technology with business outcomes. Garrett’s career has spanned a variety of roles—from service desk technician to senior network engineer—and now, as Vice President of
Solution Consulting, he leads with a hands-on, business-focused approach. He holds several industry-recognized certifications, including CCNA Route & Switch, CCNA Security, CCNA Wireless, MCSA: Server 2012 R2, MCSA: O365 Administration, NSE 1–3, and CMNA.
Ready to take your next step?
Contact us today to get the outside perspective you need for the next step on your journey.
