Post-Merger Tenant Consolidation Moving 1,600 Users Into a Single Microsoft 365 Tenant
Eighteen months after the merger the two firms still ran separate tenants, separate domains and separate everything. We consolidated 1,650 mailboxes, 720 SharePoint sites and 430 teams into one tenant with a managed coexistence period and no mail loss.
About the Client
The Challenge
The two firms had completed legally and then discovered what every merged organisation discovers: the commercial integration is quick and the technology integration is not. Eighteen months in they were still running two Microsoft 365 tenants. People had accounts in one and guest access to the other, which meant two sets of credentials, two Teams clients' worth of switching, and no directory anybody could search.
The practical cost showed up in ordinary work. Calendars did not show free/busy across the boundary, so scheduling a joint client meeting took three emails. Documents were shared by link between tenants and accumulated in personal OneDrive folders because there was no shared site to put them in. Two separate licence agreements renewed on different dates, with overlapping add-ons and a meaningful number of accounts still licensed for people who had left during the integration.
There were harder constraints underneath. Both firms used their own primary email domain and both wanted to keep sending from it, but a domain can only be verified in one Microsoft 365 tenant at a time — which makes domain cutover a hard, scheduled, irreversible-feeling event rather than something you phase. Both tenants had retention policies and legal holds in place for regulated client work, and retention configuration does not travel with a mailbox.
Finally, nobody wanted a big-bang weekend. The firm bills by the hour and a Monday morning where email does not work is measurable in a way IT projects usually are not. The requirement was a phased move with a coexistence period long enough to absorb problems and short enough that people did not settle into it.
Our Approach
We sequenced the move so the irreversible steps happened last and every reversible step was proven on a pilot wave first.
Discovery and Target Tenant Decision (Weeks 1-4)
Inventoried both tenants: mailboxes and their sizes, archives, shared and resource mailboxes, public folders, SharePoint sites, Teams and their channel structures, OneDrive volumes, Entra app registrations, conditional access policies, Intune configuration, retention policies and active legal holds. Chose the surviving tenant on the basis of licence agreement terms, existing compliance configuration and the smaller migration volume, not on which firm was nominally the acquirer. Documented 9 domains and every application that sent mail through either tenant.
Identity and Coexistence Foundation (Weeks 3-8)
Established cross-tenant access settings for B2B trust between the two organisations, then built the coexistence layer: organization relationships so free/busy worked across the boundary, and a synchronised set of mail contacts so each directory showed the other firm's people. Prepared the target identity model — Entra ID Connect scope, UPN standard, source anchor and conditional access policy parity — and ran an MFA re-registration campaign for the moving population, since authentication methods do not migrate.
Cross-Tenant Mailbox Migration (Weeks 7-16)
Used native cross-tenant mailbox migration: a migration application registered and consented in both tenants, mail-enabled user objects pre-staged in the target carrying the source ExchangeGuid, ArchiveGuid and the LegacyExchangeDN written back as an X500 proxy address so historic replies still resolve. Moved users in waves of 200 aligned to practice groups so a team moved together, with pre-sync running for days ahead of each wave and only the delta completing at cutover.
SharePoint, Teams and Content (Weeks 9-20)
Migrated 720 SharePoint sites and OneDrive accounts with permissions mapped to target groups, and rebuilt 430 teams in the target with their channel files moved and membership reconstructed. Set expectations early on the part nobody likes: private chat history does not move, so we agreed a retention and export policy for it rather than promising a migration that does not exist. Content restructuring followed our SharePoint migration practice.
Domain Cutover and Decommission (Weeks 18-24)
Sequenced the domain move precisely: remove every proxy address referencing the domain in the source tenant, remove the domain, add and verify it in the target, restamp addresses, then move MX and Autodiscover. Repointed the applications and devices that relayed mail through the old tenant before cutover, not after — that list is always longer than anyone expects. Reapplied retention policies and legal holds in the target, validated them, then decommissioned the source tenant and cancelled the duplicate licence agreement at its term date. The saving was modelled against the pricing in force after 1 July 2026, when Microsoft raised enterprise suite prices and added Microsoft 365 E7 alongside E5, because a consolidation business case built on last year's rate card does not survive procurement.
Solution Architecture
Identity: Single Entra ID tenant with a unified UPN standard, conditional access parity established before migration, and cross-tenant access settings providing B2B trust during coexistence
Mail: Native cross-tenant mailbox migration with pre-staged mail users, ExchangeGuid and ArchiveGuid preservation, and LegacyExchangeDN carried as an X500 address so old replies resolve
Coexistence: Organization relationships for cross-tenant free/busy, synchronised directory contacts for a searchable combined address list, and Teams external access for the transition period
Content: SharePoint sites and OneDrive migrated with permissions mapped to target groups; teams rebuilt with channel files moved and membership reconstructed
Compliance: Retention policies, labels and legal holds rebuilt and validated in the target before source decommission, coordinated with records management
Results
Client identity withheld under confidentiality. Figures are representative of engagements of this scope.
Technologies Used
Key Takeaways
If your organization is facing a similar challenge, here's what we learned:
Choose the surviving tenant on configuration, not on org chart. The tenant with the stronger compliance configuration, the better licence terms and the smaller migration volume should win. Letting the acquirer's tenant survive by default has caused more rework than any other decision in this category.
Domain cutover is the only genuinely irreversible step. A domain lives in one tenant at a time, so removing it from the source and verifying it in the target is a scheduled event with a rehearsal, a rollback story and a communications plan. Everything else in a tenant consolidation can be re-run.
X500 addresses are what stop replies bouncing. Carrying the source LegacyExchangeDN into the target as an X500 proxy address is a small configuration step that prevents a large class of "my reply to last month's email failed" tickets in the first week.
Chat history does not migrate — say so on day one. Private Teams chat does not move between tenants. Agreeing an export and retention position early is a manageable conversation. Discovering it in week twenty is not.
Retention and holds do not travel with the mailbox. Policies, labels and legal holds are tenant configuration and have to be rebuilt and validated in the target before the source is decommissioned. We place Microsoft 365 compliance architects on exactly this work.
Still Running Two Tenants After the Deal Closed?
Every month of coexistence costs duplicate licences and lost collaboration. We scope the consolidation, sequence the irreversible steps and run the waves.