20+ years with Microsoft 1,100+ organisations under management 131 countries invoiced locally 5 of 6 Solutions Partner designations 4-hour first response
IT Partner.Microsoft Solutions Partner +44 20 8142 5752 Talk to us Get a quote

HomeServices › Tenant consolidation

ConsultingMigrationMergers & acquisitions

Two companies, one tenant, before the integration deadline

Tenant consolidation after M&A, or a carve-out on divestiture

One accountable plan for bringing two or more Microsoft 365 tenants together — or carving one out. Dual-tenant discovery, target architecture, licensing reconciliation, a wave plan with rollback gates, and day-one coexistence so both businesses keep working. Not fifteen disconnected migrations with nobody holding the schedule.

Typical timeline10–14 weeks
Engagement ownerAlex Makey
PriceFixed, after scoping
Invoiced inYour currency
01 — Overview

What this engagement is

There is no merge button. Two Microsoft 365 tenants cannot be joined, and a division cannot be split out, by any switch Microsoft provides. Every consolidation decomposes into a sequence of moves — identities, mailboxes, archives, SharePoint sites, Teams, OneDrive, domains, sometimes Azure — each with its own tooling, its own limits and its own way of failing.

Tenant 1 Tenant 2 Tenant 3 Tenant 4 Tenant 5 Tenant 6 Tenant 7 Tenant 8 Group HQ Operating company Divested unit BEFORE · 8 TENANTS AFTER · 3 TENANTS
A group in the UAE and Singapore: eight tenants into three, with one carved back out eighteen months later.

The individual moves are the part we have done most often. What consolidations actually fail on is everything between them: putting them in an order that works, keeping both businesses operating while the waves run, reconciling two licensing agreements before renewal dates lock them in, and holding a dozen workstreams to one schedule when the deal date moves.

That coordination is what this engagement is. It runs in both directions: acquirers use it to collapse acquired tenants into one, sellers use it to carve a division into a clean tenant before a transaction closes, usually against a transitional service agreement deadline.

We have run it at every size that matters. Seventeen tenants into one for a healthcare group in Australia. Eight into three for a group in the UAE and Singapore, then one carved back out eighteen months later when they divested. Three thousand users and 24 TB across a European relocation, with no planned downtime. The write-ups, including the project where the migration host died mid-flight, are published.

02 — Outcomes

What you get out of it

The success criteria we hold ourselves to, and what the closing report has to show.

01A written assessment covering every workload in every tenant in scope — so nobody discovers a forgotten shared mailbox or an unlicensed workload during cutover weekend
02A target architecture both sides have signed: identity design, naming conventions, domain plan and licensing model, decided once and on paper rather than argued at 2am
03A wave-by-wave sequence with dependencies, entry and exit criteria, and explicit rollback gates — you know what happens if a wave fails, before it runs
04Both organisations operational throughout. Mail flows, meetings happen, files open. Our consolidations have not required planned downtime
05Licensing reconciled across the source agreements, with duplicate and orphaned subscriptions found before renewal dates make them permanent for another year
06Users on both sides told what changes and when, before it happens rather than after
07A closing report documenting what moved, what was decommissioned and when — clean enough for an auditor, a board or a buyer’s diligence team
03 — Deliverables

What you receive

Documents, not slides. Each one exists because a project went wrong without it.

Consolidation assessment. Inventory across every tenant: identities and duplicates, domains, mailbox count and size distribution, archives, SharePoint and OneDrive volumes, Teams, devices, licensing, third-party integrations, and anything under retention or legal hold.
Mailbox size distribution report. Sorted descending, not averaged. The top ten rows tell you more about the schedule than the headcount does, and this is where six-month archives surface.
Target architecture decision record. Entra ID and identity design, naming conventions, domain and alias mapping, and the coexistence model for the transition period.
Identity mapping and duplicate resolution list. Every person who exists in more than one tenant, with an explicit decision on each: merge or keep separate. On both of our largest consolidations, more than half were deliberately kept separate.
Licensing reconciliation. Subscriptions across both agreements, duplicate spend, orphaned licences, and a transition schedule that respects renewal dates. Includes the commitment-term recommendation — which seats belong on an annual term and which should stay monthly through the transition.
Wave plan. Every move scoped and scheduled, with order, dependencies, entry and exit criteria and rollback gates.
Coexistence and cutover runbook. How mail, calendars, chat and files work across the tenant boundary while waves run, plus the cutover-day checklist and the domain timing.
Communications pack. Drafted announcements, timeline notices and day-one instructions for users on both sides, ready for your branding.
Risk register and decision log, maintained across the programme rather than written at the end.
Validation and decommission checklist. What to verify in the target, and what to retire — tenants, domains, DNS, licences, third-party contracts — once it holds.
04 — Plan

How the work unfolds

Weeks are indicative for a two-tenant consolidation of moderate size. Your quote states the schedule for your deal.

WK 1–2 Discovery WK 2–3 Architecture WK 3–4 Sequencing WK 3–4 Coexistence WK 4–10 Waves PER WAVE Cutover FINAL Closure
Indicative weeks for a two-tenant consolidation of moderate size. Large archives start on day one regardless of where the rest of the plan has reached.
Weeks 1–2

Discovery and inventory

Read-only assessment of every tenant in scope. Nothing changes. Users, domains, workloads, data volumes, licensing, security posture, third-party dependencies. Duplicate licensing surfaces here, before anything moves, which is often the first thing that pays for the engagement.

Weeks 2–3

Target architecture

Identity design, naming conventions, domain strategy and the licensing model for the combined or carved-out organisation. This is where the arguments happen, on paper. It is also where we tell you which parts of the schedule are fixed by the platform and not by us.

Weeks 3–4

Sequencing and scoping

Each workload move is scoped, then assembled into a wave plan with dependencies and rollback gates. Domain timing drives much of it, because a custom domain can only be attached to one tenant at a time.

Weeks 3–4

Coexistence design

How mail, calendars, chat and files behave across the tenant boundary while the waves run. Designed before the first wave, not discovered during it.

Weeks 4–10

Wave execution

Identities first, then data, then decommission. Large archives start on day one and run in the background regardless of where the rest of the plan has reached — they finish when they finish. Each wave ends with its own validation.

Per wave plan

Cutover and day-one support

Domain moves, final identity switches, and the communications that go with them. Executed from the runbook, with rollback gates honoured rather than skipped to hit a date.

Final week

Validation and closure

Target-state verification, source decommission checklist, licence cleanup against renewal dates, and the closing report with the full paper trail.

Two tenants, or twelve?

Send us the tenant count, the rough headcount and what is forcing the date — a close, a TSA expiry, or nothing yet. We come back with the sequence, an honest view of what will be slow, and a fixed price.

Fixed, after scoping · 10–14 weeks
05 — Before we start

What we need from you

Global Administrator or equivalent delegated access to each tenant in scope, for the read-only discovery phase — our readiness checklist lists what else to have ready
A named decision-maker on each side empowered to sign the target architecture and the wave plan — the single most common cause of slippage is an unsigned decision, not a technical problem
Visibility of the deal constraints that drive the schedule: close date, TSA expiry, renewal dates on existing agreements
Legal or compliance sign-off channels for anything under retention or legal hold in the source tenants
For carve-outs, clarity on which users, domains and data belong to the divested entity
For German entities, an early conversation with the works council if the programme includes any endpoint management — see why that has to start in parallel
06 — Working together

Who does what

Split out explicitly, because the two most common causes of delay are an unsigned decision and an assumption about who owned it.

IT Partner

  • Run discovery across every tenant and produce the assessment, including the mailbox size distribution
  • Design and document the target architecture and the coexistence model
  • Scope, sequence and schedule every workload move, with rollback gates
  • Execute the migrations with our own engineers — not subcontracted
  • Reconcile licensing across both agreements and recommend the commitment terms
  • Draft the communications pack and the day-one runbook
  • Hold one schedule, one risk register and one named owner across the programme
  • Validate the end state and deliver the decommission checklist and closing report
  • Invoice from the entity that contracts in your country, in your currency

Your team

  • Grant read-only discovery access and name the decision-makers
  • Make the target-architecture decisions the plan puts in front of you: naming, domains, licensing model
  • Decide which duplicate identities merge and which stay separate — we recommend, you own it
  • Decide what does not need to move. This is the largest single lever on the schedule and it is entirely yours
  • Approve each wave before it executes
  • Brand and send the communications, unless agreed otherwise
  • Own legal, HR and regulatory decisions the consolidation surfaces
  • Confirm decommission of source tenants, domains and contracts after validation
07 — Scope

What is not included

×Legal, HR, tax or regulatory advice. We surface the IT decisions; your counsel makes them.
×Drafting transitional service agreements. We plan to your TSA’s dates and constraints. We do not write it.
×Microsoft licence purchases. Subscriptions are bought under your agreements. We can quote them separately as your CSP, in your currency, but nothing here requires it.
×Line-of-business application rework. Third-party integrations are inventoried and pointed at; re-engineering them is scoped separately when discovery finds it.
×Microsoft Sentinel and Copilot deployment. We have delivered no projects in either, so we do not sell them. If your consolidation needs them, we will say so and point you elsewhere.
×Ongoing managed services after closure. Available separately at €150 / £120 / $150 per hour if you want the combined tenant run by us.
08 — Fine print

Limitations and technical notes

The constraints that are fixed by the platform rather than by us, and the ones we learned the expensive way.

!A custom domain can exist in only one tenant at a time. Domain moves are hard sequencing constraints, not preferences. The wave plan is built around them.
!Concurrency, not bandwidth, sets the schedule. Mailbox moves run a limited number at a time — around twenty in our projects. With a thousand users that alone is fifty passes through the queue. No commercial arrangement raises the ceiling. The arithmetic is here.
!Very large personal archives run on their own clock. On one engagement several users held archives of roughly 2 TB each; those mailboxes took over six months while everything else completed around them. They start on day one for that reason.
!Bulk clean-up after a failed pass is far harder than it used to be. Microsoft previously allowed bulk mailbox operations at 10,000 objects per pass, which made large-scale remediation feasible. That is no longer available at the same scale, so prevention now matters more than recovery.
!Not everything migrates with full fidelity. Teams private chat history and certain metadata have real limits. We state them per workload during scoping rather than discovering them together at cutover.
!Holds and retention policies are tenant configuration, not data. They must be re-created in the target. Discovery inventories them so nothing under hold moves without compliance sign-off.
!Conditional Access policies do not migrate. They are rebuilt in the target tenant. If nobody mentions they exist, users discover it on the Monday after cutover.
!Ten to fourteen weeks is typical for a two-tenant consolidation of moderate size. Multi-tenant roll-ups, large data volumes, TSA constraints and third-party dependencies extend it. Your quote states the schedule for your deal, not a template.
!Discovery is read-only. Nothing changes in any tenant until you have approved the wave plan and the scope of each wave.
!If the deal terms change, the plan is re-baselined under change control rather than quietly improvised around.
09 — Questions

Asked on almost every first call

Do you run the migrations, or only plan them?

Both, with our own engineers. The programme covers assessment, architecture, sequencing, coexistence, communications and orchestration; the workload moves are executed by the same team. There is no handover to a subcontractor halfway through, and no third party seeing your data that you have not been told about.

How long does a tenant consolidation take?

Ten to fourteen weeks is typical for a two-tenant consolidation of moderate size: roughly two weeks of discovery, two of architecture and sequencing, and the rest execution and closure. Under 100 users can run shorter. A thousand or more usually runs six months or longer. The honest variables are data volume, tenant count, TSA dates and how quickly decisions get signed.

Can both companies keep working from day one?

That is the design goal of the coexistence plan, and it is what we have delivered. Mail flow, calendaring, chat and file access across the tenant boundary are designed before the first wave runs. Our consolidations have not required planned downtime, including a 3,000-user relocation moving 24 TB.

What does it cost?

A fixed price, quoted after we have looked at both tenants. Scoping costs you nothing, and the calculator will give you a first number before you speak to anyone. The price is driven by user count, how much data actually needs to move, and how tangled the identities are — not by how long the project ends up taking us. No hourly billing and no variation orders.

We are divesting, not acquiring. Does this apply?

Yes — a carve-out is the same discipline 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 out. We have done both for the same client group: eight tenants into three, then one carved back out eighteen months later. Sellers usually run this against a TSA expiry rather than a convenience date.

Can users keep their email addresses?

If the domain moves with them, yes. But a custom domain can be attached to only one tenant at a time, so the domain move is a scheduled cutover event rather than a gradual transition. Where an acquired brand is being retired, users typically take the acquirer’s domain with the old address preserved as an alias. The domain plan is decided in the architecture phase, before any wave runs.

What happens to people who exist in both tenants?

They are mapped and decided case by case. Some merge into a single identity; some stay separate because they genuinely hold different roles in different parts of the business. On both of our largest consolidations, more than half were deliberately kept separate. Merging identities that belong to different roles creates more problems than it solves.

Do we have to move everything?

No, and usually you should not. Archived mail nobody has opened in years is the largest single driver of migration time. We push hard at kick-off to agree what has to move, what can be archived elsewhere and what can be left behind under a retention policy. It is an uncomfortable conversation at kick-off and a far worse one in month five.

We have a hard TSA deadline. Will the schedule hold?

TSA expiry is treated as a fixed constraint from day one: the plan is built backwards from it and the riskiest dependencies are scheduled earliest, so slippage is visible in week two rather than week seven. What we will not do is compress validation to hit a date. If the deadline and the scope genuinely conflict, you hear it during sequencing while there is still time to renegotiate.

Who owns the tenant afterwards?

You do, entirely. We act as Cloud Solution Provider of record for the subscriptions only if you want us to, and that can be changed at any time. Nothing about the consolidation locks you to us.

Which entity would invoice us?

Whichever of ours is authorised for your country, in the currency Microsoft sets for it — euros, sterling, francs, kronor, kroner, dirhams, Australian or Canadian dollars. For a group with entities in several countries, each gets a local invoice under one relationship. The United States is served by our headquarters location at o365hq.com.

What could make this take twice as long?

Four things, and we will tell you in week two if any of them apply: personal archives above 100 GB, an unsigned target architecture, a works council approval that was not started in parallel, and a third-party application that authenticates against the source tenant and nobody owns. None of them are exotic. All of them are visible during discovery if someone looks.

10 — Related

Read before you commit

Scoping costs nothing

Tell us the shape of the deal and we will tell you what it involves

How many tenants, roughly how many users, and what is forcing the timing — a close date, a TSA expiry, or nothing yet. You get back a sequence, an honest view of what will be slow, and a fixed price. Usually within one business day, and nobody rings you unless you ask.