Two companies. Two AD forests. One merger.
The technical question every integration team eventually faces: do we consolidate the forests, or do we run them in coexistence?
The answer is almost never obvious. And the wrong choice costs more than just money — it costs integration velocity, user productivity, and security posture.
The Fundamental Trade-off
Forest consolidation means merging all users, groups, and resources into a single AD forest. One identity store. One set of GPOs. One domain to manage forever.
- Timeline: 6-18 months for complex environments
- Cost: $300K-$2M depending on application count and user base
- Complexity: Extremely high — requires application re-linking, DNS cutover, SID history management, and massive user communication
- Long-term outcome: Clean. One forest to rule them all.
Coexistence means maintaining both forests long-term, with some form of identity synchronization between them (Azure AD Connect, Microsoft Identity Manager, third-party tools).
- Timeline: Initial sync setup is 4-8 weeks; indefinite maintenance thereafter
- Cost: $50K-$200K to set up, plus ongoing operational overhead
- Complexity: Lower initial lift, but compounding complexity over time
- Long-term outcome: Two forests forever. Two sets of policies. Two attack surfaces.
The Decision Matrix
| Factor | Consolidate | Coexist |
|---|---|---|
| User count (< 2,000 combined) | ✅ Often worth it | ✅ Often sufficient |
| User count (> 5,000 combined) | ⚠️ Cost-benefit needed | ⚠️ Operational burden significant |
| High regulatory environment (finance, healthcare, defense) | ✅ Consolidation preferred | ❌ Fragmentation is audit risk |
| Post-merger brand integration required | ✅ Consolidation required | ❌ Brand integration harder with split identity |
| M365 tenant count (2 separate tenants) | ⚠️ Requires M365 cutover planning | ⚠️ Multi-tenant complexity |
| On-prem app dependency heavy | ⚠️ App re-linkage required | ✅ Lower risk |
| Greenfield cloud adoption planned | ✅ Good time to consolidate | ❌ Adds another forest to migrate later |
| PE firm with 5+ portfolio companies | ❌ Each deal adds another forest | ✅ Faster per-deal |
| Short integration timeline (< 6 months) | ❌ Almost never feasible | ✅ Often the only option |
When to Consolidate
Do it when: The merged entity has a unified brand, shared infrastructure, and the IT team has the bandwidth to manage the migration properly. In practice, this means large corporate M&A where Day 1 has already passed and the integration team is fully operational.
The tell-tale sign that consolidation is right: the business case for coexistence (speed) is actually just delay. “We’ll coexist for 2 years and then migrate” is almost always a plan to never migrate.
The actual process:
- Weeks 1-4: Discover all applications and their AD dependencies. Every app that authenticates against the source domain must be documented.
- Weeks 5-12: Build the target forest. Design OU structure, GPOs, site/subnet definitions. Establish trust relationship.
- Weeks 13-24: Run pilot migrations. Migrate service accounts first (no user disruption). Then pilot departments.
- Weeks 25-40: Full user migration waves. Run ADMT (Active Directory Migration Tool) for user and group account migration with SID History preservation.
- Weeks 41-52: Decommission source forest. Clean up DNS, certificate templates, and trust relationships.
Total: 9-12 months for a 3,000-user environment with moderate app complexity.
When to Coexist
Do it when: Deal velocity is high, integration timeline is short, or the acquired company has significant operational independence (common in PE add-on acquisitions where the acquired company keeps operating as-is).
Coexistence is explicitly the right answer in these scenarios:
- Add-on acquisitions where the acquired company continues to run its own IT environment with minimal integration
- Divestitures where the carved-out entity needs to be separated but can’t be fully separated on Day 1
- Regulated industries where changing the user identity environment requires re-certification of systems
The coexistence architecture looks like this:
Source Forest (acquired.company.com)
↓
Azure AD Connect (passthrough auth or federation)
↓
Target Forest (merged.company.com)
↓
Azure AD (single tenant for M365)
Users in the source forest get SSO to M365 through the target tenant via the trust relationship. This works, but has pitfalls: S2S VPN dependencies for on-prem app access, Split DNS management, conditional access policies that apply differently to each forest’s users.
The ACQI Module Angle
ACQI’s identity discovery captures which forest each application authenticates against, which users have mailboxes in which Exchange organizations, which Azure AD tenants are in play, and what the identity dependency graph looks like across both environments. This becomes the migration planning document — and it’s what most teams have to build from scratch because nobody audited the identity estate before the deal.
That’s why the decision matrix so often gets made on the back of incomplete data. The forest migration decision should happen in due diligence, not 60 days post-close.
The Honest Answer
Most integrations should consolidate. The operational overhead of coexistence is systematically underestimated, the security implications of maintaining two identity stores are systematically ignored, and the “we’ll migrate later” plan almost never gets executed.
The exceptions are real: add-on acquisitions, regulated environments, and situations where deal velocity makes consolidation impossible. But those are exceptions, not the default.
The default should be: consolidate by design, coexist by exception.