Identity integration after a merger or carve-out
Cohash does the identity work when companies merge or split up. Day one is cross-tenant access, B2B collaboration or cross-tenant synchronization, so people can get to the apps they need. Then we go in planned waves. HR sources and directories are merged or separated, and so are identity providers, governance and privileged access. Before that, we correlate each user's accounts and review every privileged path across the boundary.
- 01Day-one access
- 02Inventory both estates
- 03Lock down privileged paths first
- 04Merge HR and correlate people
- 05Move in waves
- 06Retire or separate
The story
Told without the client's name or anything that could identify them.
An acquiring company's identity team was weeks from deal close, with each side running its own directory, identity provider and IGA tool, and people on both sides needing Teams, SharePoint and a handful of business apps on day one. Administrators on the acquired side also still held privileged access they no longer needed. We scoped cross-tenant access and synchronization to named apps for day one, then inventoried both estates and cut back the admin accounts, trusts and federation links that crossed the boundary. HR sources were combined, accounts were correlated person by person, and users and apps moved in waves by business unit until cross-tenant sync and the second tenant could be retired.
why it was urgentDeal close sets day one, and a carve-out's transition services agreement sets the date the seller's identity services stop. Microsoft states that Entra cross-tenant synchronization is not a migration tool, because synced users still authenticate in their source tenant. It bridges access for day one, but the real consolidation or separation is a separate project.
- openThe deal closes in a few weeks, and people on both sides need Teams, SharePoint and a handful of business apps.
- recurringBoth sides run their own directory, identity provider and IGA tool, and neither set of contracts has ended.
- blockedA carve-out's TSA says identity and email services end on a fixed date.
- openAdministrators on one side still hold privileged access on the other.
The estate, before and after
Before: two identity estates joined by trusts and shared admins
Each company fed its own directory and IGA tool from its own HR system. Domain trusts, federation links and shared admin accounts gave administrators on one side reach into the other.
Read the diagram as text
- HR system (company A) → Entra ID tenant A: joiner · leaver
- HR system (company B) → Identity provider B: joiner · leaver
- Entra ID tenant A → Domain trusts and federation: federation
- Identity provider B → Domain trusts and federation: trust
- Entra ID tenant A → IGA tool A: aggregation
- Identity provider B → IGA tool B: aggregation
- Domain trusts and federation → Shared admin accounts: cross-side access
After: one HR source, one governance platform, one tenant
One combined HR source now feeds a single IGA platform, and that platform provisions the target Entra ID tenant and privileged access. After the last wave, everyone signs in to Teams, SharePoint and the business apps from the same tenant.
Read the diagram as text
- Combined HR source → IGA platform: joiner · mover · leaver
- IGA platform → Target Entra ID tenant: provision
- IGA platform → Privileged access: safe membership
- Target Entra ID tenant → Teams and SharePoint: sign-in
- Target Entra ID tenant → Business apps: SSO
- Privileged access → Business apps: admin access
How we run it, phase by phase.
6 phases take you from Two identity estates after a deal to One governed identity model. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Day-one access
For day one we combine cross-tenant access settings and automatic redemption with cross-tenant synchronization or B2B invitations, and open up named apps only. Scope is what day one needs. Not everyone gets everything.
- phase 02
Inventory both estates
We inventory both sides: directories, tenants, identity providers, IGA and PAM tools, HR systems, then the privileged accounts, service accounts and AI agents. Every line gets an owner and a contract date.
- phase 03
Lock down privileged paths first
We review every admin account, trust, federation link and shared service account that crosses the boundary, and cut back what isn't needed. In a carve-out they're removed first, before a single user moves.
- phase 04
Merge HR and correlate people
HR sources get combined or split, and every person's accounts are matched across the two sides. Duplicates, rehires and contractors the rules can't sort out, we resolve by hand.
- phase 05
Move in waves
We move users, groups, apps and mailboxes to the target tenant or identity provider in business-unit waves, and compare access before and after each one.
- phase 06
Retire or separate
At the end, cross-tenant sync and the old trusts come out. We shut down the second tenant or identity provider, or hand it to the buyer, and keep audit history for both sides.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Day-one access was limited to named apps
Cross-tenant settings and sync scope groups were set per app, so people got Teams, SharePoint and the agreed business apps without everyone being synced into everything.
- result 02
Privileged paths across the boundary were removed first
Shared admin accounts, domain trusts and federation links got reviewed and cut back before a single user moved. Each removal is in the log.
- result 03
Each person maps to one identity
Correlation rules tested on real HR data matched accounts across both sides, and duplicates, rehires and contractors the rules couldn't decide were resolved by hand.
- result 04
One tenant and one governance model
We moved users, groups and apps in waves and compared access before and after each one. Once the last wave landed, cross-tenant sync and the old trusts came out, and both sides kept their audit history.
Risks we plan for
-
Over-broad day-one access
Syncing everyone into the other tenant is quick and hard to undo. Scope groups are set per app, and the list is reviewed at each wave.
-
Privileged access across the boundary
Domain trusts, shared admin accounts and federation links give one company's admins reach into the other. They're the first thing an attacker would use, so they go first.
-
Duplicate identities and email conflicts
Correlation trips over people who share a name, and over people who worked at both companies. That's why we test matching rules on real HR data before we merge a single account.
-
Sync limits taken for a migration
Cross-tenant synchronization doesn't sync nested groups, needs Entra ID P1 for each synced user in the source tenant, and can't move mailboxes or files. Planning on it as the end state leaves work undone.
Where AI helps, and where it needs guardrails
Microsoft 365 Copilot and other assistants in the acquired tenant work within existing permissions. So oversharing on SharePoint becomes visible to new colleagues fast. Before access is merged, agents and MCP servers on both sides need an inventory with owners. Entra Agent ID or Okta for AI Agents can hold that register. AI can suggest identity matches across HR records, but a person confirms each merge.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- design01
Day-one access design with scoped cross-tenant settings
yours to keep - inventory02
Inventory of both identity estates with owners and contract dates
yours to keep - report03
Privileged access review across the boundary, with removals logged
yours to keep - document04
Identity correlation rules and exception list
yours to keep - plan05
Wave plan through to tenant or identity provider retirement
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Service account
- A non-human account that software signs in with. Shared ones tend to pick up years of extra permissions.in context →
- 02Wave
- One batch of workloads moved together. Large migrations run as a series of these, so each one can be planned, cut over and reviewed on its own.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01What has to be ready on day one?
Usually email reachability, Teams and SharePoint collaboration, and a short list of business apps. We agree that list with leadership and keep day one to it, so the long-term design isn't decided under deadline.
02Is cross-tenant synchronization enough?
Often, for collaboration. For a full merge, no. Microsoft is clear it isn't a migration tool. Users keep signing in to their home tenant, and mailboxes and files stay where they are.
03How do you handle a carve-out?
Privileged access across the boundary goes first. Then we build a copy of the identities and groups the new company needs, apps move, and the seller removes access when the TSA ends. The TSA sets the dates.
04Which tenant or identity provider should we keep?
It depends on size, licensing, regulatory needs and which side's apps are harder to move. The larger estate isn't always the right target. We compare both before anyone commits.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case study77bd6c57 - 01Microsoft Learn: What is cross-tenant synchronization in Microsoft Entra ID?learn.microsoft.com ↗
- 02Microsoft Learn: What's new in Microsoft Entra Agent IDlearn.microsoft.com ↗
- 03Okta support: What's new in Okta for AI Agentssupport.okta.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it