Clouds Connected · Case study
Programme studyHealthcare

Six merging health organisations consolidated onto one directory and one Microsoft 365 tenant, with all 18 identity collisions resolved before a single mailbox moved.

An Active Directory and Microsoft 365 consolidation for six community health organisations becoming one provider, where the hard problem was never the mailboxes but the eighteen people whose identities did not resolve cleanly.

Client
Six community health organisations merging into one provider
Sector
Healthcare
Engagement
Active Directory and Microsoft 365 consolidation into a new Azure environment
Period
November 2023 – May 2024
Anonymised

The client is anonymised, and every figure on this page traces to dated project correspondence. Quotes are verbatim, with their clearance status shown against each one. Named references are available on request. Nothing here has been estimated or rounded up.

In brief

Active Directory merger consolidation: what this engagement covered

The challenge

Six community health organisations were becoming one provider, each with its own Active Directory, its own Microsoft 365 tenant, its own naming conventions and its own record of who a person is.

That last part was the work. When six directories merge, some people already sit in two of them: a clinician working across two organisations, an administrator covering a second site. Thirteen people held accounts in more than one tenant. Five had the same account name in two different domains. Each is a question about a real person rather than a technical problem, and no mailbox could move until all eighteen were answered.

Underneath sat a question nobody could defer: build a new environment, or inherit one, against a merger timetable that was not going to wait.

The solution

The architecture decision was made once, in writing, and authorised. On 7 March 2024 the incoming chief executive approved building a new Active Directory environment in Azure and migrating every organisation into it, while retaining one organisation’s existing Microsoft 365 tenant and renaming it to the merged entity. The inherited tenant carried its own history and licensing, and it saved months. What matters is that the trade was chosen deliberately, by someone with the authority, on a date.

The next day the IT lead of the organisation whose tenant was being kept put a continuity risk on the record: consolidating into Azure meant abandoning a multi-cloud position and accepting single-vendor dependency.

Identity was resolved person by person before anything moved. The migration OU held 179 users: four disabled, thirteen whose primary domain lay elsewhere, and 162 migrated. Each of the five duplicate account names got a decision on which directory identity survives, and the obvious answer was not always the right one, because the surviving account determines what the person keeps. The thirteen holding accounts in more than one tenant had their content consolidated into a single new identity, which is a different exercise from moving a mailbox.

Every address changed at the same time as everything else. The merged organisation moved to a firstname.lastname convention on a new domain, so a person’s login, email address and display name all changed on the weekend their mailbox moved. Cutovers were staged by service area, with dates published to staff in advance.

The results

162 of 179users migrated from one organisation’s directory, with 4 disabled and 13 on another primary domain
18identity collisions resolved person by person before any migration ran
78 of 80mailboxes in the first mail run; the two that failed completed the same day
BeforeAfter
Directoriessix, one per organisationone Active Directory environment in Azure
Microsoft 365 tenantssixone, inherited from an existing organisation and renamed
A person in two organisationstwo accounts, two mailboxes, sometimes two namesone identity, content consolidated
Account namingsix conventionsfirstname.lastname on the merged domain
First mail run78 of 80 mailboxes, two blocked by forwarding rules80 of 80 the same day

The two mailboxes that failed carried forwarding rules pointing at addresses that would not exist after the move; ignoring those rules let both complete, at the cost of those users’ rules. Shared mailboxes, resources and contacts were migrated as their own pass. The programme ran from November 2023 to May 2024, with Clouds Connected as technical lead under the managed services partner holding the client relationship.

The part worth carrying into the next merger is that the hard problem was never the mailboxes. It was eighteen people whose identities did not resolve cleanly, each needing a human decision.

Technologies

Questions we get asked

Active Directory merger consolidation: common questions

What makes a multi-organisation merger hard to migrate?
Identity collisions, not mailboxes. When directories merge some people already exist in two of them, and a duplicated account name has to become one account, so someone decides which identity survives and what the person loses. In this six-organisation health merger that was 18 people, and it gated every migration behind it.
Should a merged organisation build a new Microsoft 365 tenant or inherit one?
Both are defensible, and the choice should be explicit and dated. This merger inherited one organisation's tenant and renamed it, approved by the incoming chief executive on 7 March 2024. That saved months but carried the inherited tenant's history and configuration into the merged entity, which is expensive to revisit later.
How do you handle someone with accounts in more than one tenant?
Create the single new identity first, then migrate each source account's content into it. It is a consolidation rather than a mailbox move. Thirteen people here held accounts in more than one tenant, and their expectations need managing separately, because they will be looking for two sets of mail in one place.
Why do mailboxes fail in a first migration run?
Commonly, inbox rules. Two of the 80 mailboxes in one organisation's first run failed on forwarding rules pointing at addresses that would not exist after the move. Ignoring those rules let both complete the same day, at the cost of the users' rules.
Related work

Other engagements like this one

Work with us

Two ways this usually starts

For consulting partners

SharePoint delivery under your paper

Nine of the ten engagements in this library were contracted through a systems integrator, an ISV or a managed provider, with Clouds Connected as the named SharePoint delivery lead. Your client relationship, your invoice, our platform depth — white-label delivery, escalation cover, or a fixed-scope block of hours.

Every study here is anonymised by default, which is also how we work inside your accounts.

For direct clients

Upgrades, migrations, recovery, patching

SharePoint Server and Microsoft 365 platform work on estates that cannot simply be rebuilt: version upgrades, tenant and content migrations, disaster recovery design and drills, performance root-cause diagnosis, and scheduled security patching on a standing cycle.

Regulated utilities, financial services, aerospace and healthcare. Based in the Greater Toronto Area, Canada; delivery across North America.

Provenance

Where these facts come from

Reconstructed from project correspondence, September 2021 to September 2026. Every figure on this page traces to a dated message, and the source citation for each sits in the accompanying fact sheet. Nothing has been estimated, rounded up, or written on the client’s behalf.

Clouds ConnectedHealthcare · six organisations, one directory, eighteen identity collisions