Merging two directories after an acquisition

When one company acquires another, the first visible integration problem is usually identity. Two directories, two email domains, two sets of groups, and a few hundred people who need to reach shared systems by Monday.

Rushed, it produces duplicate accounts, locked-out staff and former employees who keep access. Done in phases, it is mostly bookkeeping.

This article assumes you are the acquiring side, and that the target keeps operating for a while before full integration. See the mergers and acquisitions use case for the wider scenario.

Start with a decision, not a tool

Before touching any system, decide the end state and write it on one page:

• One identity platform for everyone, with the acquired directory retired.
• Federation for an interim period, where both directories stay and the primary platform trusts the other for sign-in.
• Permanent separation, for example when the acquired business remains a distinct entity for legal or regulatory reasons.

Most acquisitions choose federation first and consolidation later. Do not skip the decision: it determines how you treat every conflict below.

Step 1: Inventory both sides

For each directory, count and classify:

• Active employees, contractors, shared mailboxes, service accounts, test accounts, and disabled accounts.
• Groups and their purpose. Many are leftovers.
• Applications that depend on the directory for sign-in or for group membership.
• Email domains and aliases in use.

Compare the totals against HR headcount. A large gap in either direction is a warning: stale accounts that should be removed, or staff with no account.

Clean before you merge. Disable accounts with no activity for six months, after confirming with managers. Merging dirt produces larger dirt.

Step 2: Choose a matching key

You need a reliable way to say "this person in directory A is the same person in directory B". Rank candidate keys by stability:

1. HR employee ID, if both companies issue one and they do not overlap. Often the best, but IDs from two firms can collide, so prefix them with a company code.
2. Official email address, usable only if one person has exactly one.
3. Name plus date of birth or joining date, only as a manual review aid.
4. Name alone: never use this for automatic matching.

A pragmatic approach is a three-bucket report:

People appear on both sides more often than you expect: a consultant who worked at both firms, a person who moved before the deal, a shared inbox named like a person.

Step 2b: Duplicate identities

A duplicate is two accounts for one person. They cause split access histories and make leaver processing unreliable. When you find them:

• Pick one as the surviving identity, normally the one that matches HR records.
• Copy over only the access still needed, rather than the union of both.
• Disable, then later delete, the other.
• Record the mapping in a table so past audit logs can still be explained.

Step 3: Naming and email collisions

Two companies will share first names. a.sharma exists on both sides, and they are different people.

• Decide the naming convention for the combined directory and apply it to new accounts only; renaming everyone invites breakage.
• Keep the acquired email domain working as an alias for as long as external parties use it. Mail bounce on day one damages trust with customers and vendors.
• Treat the email address as an attribute, not as the primary key. Applications that key on email will otherwise create a new, empty account when the address changes. Use an immutable internal identifier where applications allow it.
• Reserve usernames in advance. Check collisions with a script and resolve them in a spreadsheet, then load.

Step 4: Map groups and roles

Do not copy groups across by name. "Finance-Admins" in one company may mean something quite different in the other.

1. List each source group, its members and the access it grants.
2. Map each to a role in the target model. Use a small set of roles, not a one-to-one clone.
3. Mark groups with no clear owner. Ask the acquired company's team, and if nobody claims it, do not migrate it.
4. Keep privileged groups for last, and have an owner approve each membership personally.

If you use automatic provisioning to push users and groups to applications, see SCIM 2.0 in plain English; group mapping is where mistakes quietly propagate to every downstream app.

Step 5: Phased SSO cut-over

Avoid a single big-bang weekend. Move in waves:

1. Wave 0: IT and the pilot group, 20 to 30 people, from both companies.
2. Wave 1: one department with simple application needs.
3. Wave 2 onwards: remaining departments, grouped by the applications they use.
4. Last: executives and finance, with extra support on hand, not because they matter more but because disruption to them is costly.

For each wave: - Publish a one-page note on what changes and what to do. - Enrol the second factor beforehand, not on the day. - Integrate each application with the primary platform using SAML or OpenID Connect.

What is SSO? covers the protocols. - Keep a rollback available per application.

Temporary dual login

During the transition, people often need both. Allow the old sign-in path alongside the new for a defined period, say two to four weeks per wave, then switch it off by date. Rules for the dual period:

• Same factor policy on both paths. A weaker legacy path becomes the attack route.
• Name an end date in the announcement. Without one, "temporary" lasts three years.
• Log use of the legacy path and chase anyone still using it a week before the end date.

Step 6: Decommission properly

Retiring the old directory is the part teams postpone, and it leaves the biggest risk behind.

• Confirm every application has moved. Check sign-in logs of the old directory for anything still authenticating against it, including service accounts and scheduled jobs.
• Export and archive the old directory, its audit logs and the mapping table, in line with your retention policy; ask your compliance counsel about retention periods and the handling of personal data under the DPDP Act 2023.
• Disable first, wait thirty days, then delete.
• Remove trust relationships, shared secrets and DNS records that pointed to it.

Cut-over checklist

• Decision on end state written and signed off.
• Both directories cleaned; counts reconciled against HR.
• Matching key chosen; match report reviewed by a human.
• Duplicates resolved and mapping table saved.
• Naming convention and domain alias plan agreed.
• Group-to-role mapping approved by owners.
• Second factor enrolled before each wave.
• Rollback tested for each application.
• Dual-login end date announced.
• Old directory's sign-in log shows zero activity before disable.
• Archive complete; deletion date set.

What to do this week

• Run the inventory and count both directories against HR.
• Produce the exact, probable and no-match report.
• List the ten applications that depend on the acquired directory.
• Decide the end state, and tell stakeholders in one paragraph.
• Nominate the owners who will approve group mappings.