Situation
More than one Microsoft 365 environment
Two tenants, or three, and no single place that is authoritative. People in one cannot see calendars in the other, administration happens twice, and the security posture is whatever each environment was set up with.
Nothing is forcing the issue. There is no deal, no deadline and no outage — which is exactly why it persists, and why the cost accumulates quietly rather than arriving as a crisis.
This is a situation rather than a service. What resolves it is a consolidation, and that has its own page — what follows is how estates end up here and what the split actually costs, so you can judge whether it is worth doing anything about yet.
How estates end up this way
Every one of these was a reasonable decision at the time, and none of them was a decision to run two environments permanently.
- An acquisition nobody finished
- The deal completed, the two estates were left running side by side because everything worked well enough, and the integration slipped behind whatever came next. This is the most common one, and the tenant is often years old by the time anyone counts it.
- A tenant somebody else provisioned
- A web host or a domain registrar set up Microsoft 365 alongside the domain — GoDaddy is the usual one. It works, it bills separately, and it is frequently discovered rather than remembered.
- A department that bought its own
- A team needed something quickly and had a card. The licenses are real, the data in them is real, and nobody outside that team knows the tenant exists until a security review or a leaver goes looking.
- Growth that outran the design
- A second environment was stood up for a project, a region or a subsidiary, on the reasonable assumption it would be temporary. It was not.
What the split costs
Rarely a single large cost. Consistently a set of small ones that recur, and that get harder to unpick the longer both environments stay populated.
- Everything is administered twice
- Two sets of policies, two license pools, two places a joiner or a leaver has to be handled, and two of every change. The work does not double, but it does not halve either.
- People cannot see each other
- Free/busy does not cross a tenant boundary by default, so scheduling between the two halves is guesswork. Shared files get emailed rather than linked, and the address book is only ever half right.
- The security posture is whatever each tenant was set up with
- Conditional Access, MFA coverage, sharing defaults and retention are configured per tenant. The weaker of the two sets the real posture of the organization, and nobody is reporting on it as one estate.
- Licensing drifts
- Two agreements renewing on two dates, accounts still assigned to people who left, and duplicate licensing for anyone who needs to work in both. It is rarely visible as one number.
- Nobody is certain which one is authoritative
- Two directories, two versions of a distribution list, two copies of a document that have both been edited. The question of which is correct gets answered per incident rather than once.
What consolidating involves
Bringing the environments together is an identity problem before it is a migration. Every account that exists on both sides needs a decision. The domains have to move one at a time, and both tenants stay live while people are moved across in groups.
What makes it a project rather than a task is that the order is fixed by dependencies rather than chosen. And the order cannot be written until somebody has established what is actually in both environments.
How a tenant consolidation runs
If a transaction is what created the second environment, the sequencing question is the same but the deadline is not. M&A technology integration covers that case.
When this stops being tolerable
Two environments can run alongside each other for years. What usually changes is not the friction — it is something arriving that the split blocks.
A security or insurance questionnaire that has to be answered for the organization rather than per tenant. A licensing renewal where the duplication becomes visible as one figure. An acquisition that would add a third. Or a Copilot or data-governance project that needs one estate to reason about.
Each of those turns a background cost into a blocker, and each of them arrives with less notice than the consolidation needs.
Start by counting what is actually there
The first useful step is an inventory of both environments — what is in each, who exists twice, and what depends on which. That is what decides whether consolidating is a project or a much smaller piece of work.