Microsoft 365 Mergers & Acquisitions Tenant Consolidation
The program layer for bringing two or more Microsoft 365 tenants together — or carving one out — after a merger, acquisition, or divestiture. IT Partner runs dual-tenant discovery, designs the target architecture, consolidates licensing and billing, and sequences the individual moves — email, SharePoint, Teams, OneDrive, Entra ID, archives — each delivered through our published, separately priced tenant-to-tenant migration services. You get one accountable plan, day-1 coexistence so both companies keep working, and a documented cutover instead of fifteen disconnected migrations. The program is quoted per deal; a typical engagement runs about eight weeks.
What this engagement is
There is no merge button in Microsoft 365. Two tenants cannot be joined, and a division cannot be split off, by any switch Microsoft provides. Every consolidation decomposes into a sequence of workload moves — identities, mailboxes, SharePoint sites, Teams, OneDrive files, archives, sometimes Azure resources — and each move has its own tooling, its own constraints, and its own failure modes. The individual moves are the easy part. We run each of them as its own well-worn, separately priced service: tenant-to-tenant email migration (or the no-downtime, no-bounce variant), SharePoint, Teams, OneDrive, Entra ID (basic or staged), in-place archives, group mailboxes, shared mailboxes, Viva Engage, private Teams chats, Windows devices, and Azure resources. This page does not re-sell any of those scopes. What consolidations actually fail on is everything between the moves: sequencing them in an order that works (identities before data; a custom domain can live in only one tenant at a time), keeping both companies operational on day 1, reconciling two licensing agreements, telling users what changes and when, and holding fifteen workstreams to one schedule. That coordination layer is what this service sells — the assessment, the target architecture, the wave plan, the coexistence design, the communications, and one accountable owner across all of it. It works in both directions. Acquirers and PE operating partners use it to collapse acquired tenants into one; sellers use it to carve a division out into a clean tenant before a transaction closes, often against a transition-services-agreement deadline. The same discipline is described from the buyer's side on our Migrations and M&A Tenant Consolidation solution page — this service is the scoped engagement behind it.
Success criteria
What you receive
How the work unfolds
Read-only assessment of every tenant in scope: users, domains, workloads, data volumes, licensing, security posture, and third-party dependencies. Duplicate licensing surfaces here, before anything moves.
Identity design, naming conventions, domain strategy, and the licensing model for the combined (or carved-out) organization. The arguments happen here — on paper, not at cutover.
Each workload move is scoped as its own service with the teams that will run it, then assembled into a wave plan with dependencies, entry and exit criteria, and rollback gates. You receive per-workload quotes alongside the program plan.
How mail, calendars, chat, and files work across tenant boundaries while the waves run — including domain timing, since a custom domain can only exist in one tenant at a time.
The per-workload migrations run as their own engagements under this program's schedule and change control. We orchestrate, track, and unblock; each wave ends with its own validation.
Domain moves, final identity switches, and the communications that go with them — executed from the runbook, with rollback gates honored.
Target-state verification, source decommission checklist, license cleanup against renewal dates, and the closing report with the full paper trail.
Prerequisites
Who does what
IT Partner
- Run the discovery and produce the consolidation assessment across all tenants in scope
- Design and document the target architecture and coexistence model
- Scope, price, and schedule every per-workload migration through the matching IT Partner service
- Orchestrate the waves: one schedule, one risk register, one accountable program owner
- Prepare the communications pack and the day-1 runbook
- Validate the end state and deliver the decommission checklist and closing report
Your team
- Grant read-only discovery access to each tenant and name the decision-makers
- Make the target-architecture decisions the plan puts in front of you — naming, domains, licensing model
- Approve each wave and each per-workload scope before it executes
- Send the communications (we draft; you brand and send, unless agreed otherwise)
- Own legal, HR, and regulatory decisions the consolidation surfaces
- Confirm decommission of source tenants, domains, and contracts after validation
What's not included
Limitations & technical notes
Frequently asked questions
Do you actually run the migrations, or just plan them?
Both — but as separate, transparent line items. This program covers the assessment, architecture, sequencing, coexistence, communications, and orchestration. Each workload move — email, SharePoint, Teams, OneDrive, Entra ID, and the rest — is delivered by our own teams as its own service with its own published price, quoted alongside the program plan. You see what every piece costs, and you approve each wave before it runs.
Can both companies keep working on day 1?
That is the design goal of the coexistence plan. Mail flow, calendaring, chat, and file access across the tenant boundary are designed before the first wave runs, and for email cutovers where zero bounced messages matter we use our no-downtime, no-bounce migration method. Coexistence is transitional by definition — the plan states what works across the boundary during the program and what waits for its wave.
How long does a consolidation take?
A typical two-tenant consolidation runs about eight weeks end to end: roughly two weeks of discovery, two of architecture and sequencing, and the rest wave execution and closure. The honest variables are data volume, the number of tenants, TSA and renewal dates, and how quickly decisions get signed. Your quote includes the schedule for your specific deal, and the wave plan makes every date visible.
What does it cost?
The program layer is quoted per deal — the shape depends on how many tenants, workloads, and waves are involved. The per-workload migrations underneath it carry published fixed prices on their own service pages, so the total is assembled from visible parts rather than one opaque number. Everything is quoted in writing before work begins, and you pay after you approve delivery.
We are divesting a division, not acquiring one. Does this apply?
Yes — a carve-out is the same program run in reverse: discovery establishes what belongs to the divested entity, a clean target tenant is designed and stood up, and the waves move that division's identities, mail, and data out. Sellers typically run this against a transition services agreement, and the wave plan is built around the TSA's expiry rather than a convenience date.
Can users keep their email addresses?
If the domain moves with them, yes — but a custom domain can only be attached to one tenant at a time, so the domain move is a scheduled cutover event, not a gradual transition. Where the acquired brand is being retired, users typically get the acquirer's domain with the old address preserved as an alias during the transition. The domain plan is part of the target architecture and is decided — with your input — before any wave runs.
Will Teams chat history come across?
Team channel content migrates through the Teams tenant-to-tenant service; personal and group chats are a separate move with real, documented limits — see Microsoft Teams Private Chat Migration for exactly what survives. The program plan tells users what to expect before cutover instead of letting them find out after.
What happens to in-place archives and content under legal hold?
Archive mailboxes move through the tenant-to-tenant in-place archive service. Holds and retention policies are tenant configuration, not data — they must be re-created in the target, and discovery inventories them so nothing under hold moves without your compliance sign-off.
What about identities, devices, and sign-in on day 1?
Identity is always the first wave: users, groups, and configuration land through the Entra ID basic or staged transition service, and Windows devices re-home through our automated device migration service. The sequencing rule the plan enforces is simple: identities before data, data before decommission.
The acquired company also has Azure. Is that covered?
Azure subscriptions and resources are inventoried in discovery and moved through our Azure tenant-to-tenant resource migration service as their own wave. Azure moves have very different mechanics from Microsoft 365 workloads — which is precisely why they are a separate scope with their own service rather than a bullet point in this one.
Who tells our users what is changing?
The communications pack gives you drafted announcements, timeline notices, and day-1 instructions for both organizations, mapped to the wave plan. You brand and send them — or we agree otherwise at kickoff. In our experience the consolidations that go quietly are the ones where users heard the plan from their own leadership before anything moved.
Can you also consolidate the licensing agreements?
Yes — that is one of the more immediately valuable parts of the program. Discovery reconciles subscriptions across both organizations' agreements, flags duplicates and orphans, and the consolidation plan is built around renewal dates so you stop paying twice as early as the terms allow. As a CSP partner we can also take over the combined billing afterwards, but nothing in this program requires that.
We have a hard TSA deadline. Can the schedule hold?
TSA expiry is treated as a fixed constraint from day one: the wave plan is built backwards from it, the riskiest dependencies are scheduled earliest, and every wave has entry and exit criteria so slippage is visible in week two, not week seven. What we will not do is quietly compress validation to hit a date — if the deadline and the scope genuinely conflict, you hear it in the sequencing phase while there is still time to negotiate the TSA.