Why AD Mergers Fail
The technical steps of merging two Active Directory forests are documented. Microsoft has white papers. The process is: prepare the target forest, run a migration tool, migrate users, groups, and computers, reconfigure trust relationships, decommission the source forest.
The problem is not the process. The problem is what the process assumes: that you know what depends on the source forest. In our experience across 40+ integration post-mortems, the thing that kills AD merger timelines is the thing nobody documented — the application that authenticates through the source forest but has no owner who knows this.
The Service Account Dependency Problem
An Active Directory forest has service accounts. Service accounts run services. Services run applications. Applications support business functions.
The chain: Service Account → Service → Application → Business Function.
If you migrate the service account to the target forest but the application that depends on it is still running in the source forest, you’ve broken the service. If you migrate the application before the service account, the service stops.
The documentation problem: service accounts are documented in AD. The applications they run are documented in the application inventory. The business function is documented in the business function owners. The chain between step 1 and step 4 is almost never documented.
The Discovery You Need Before Starting
Before touching any AD merger work, you need:
1. Complete service account inventory — Every service account, what it has permissions to, what it runs, what depends on it, when the password was last rotated.
2. Application authentication mapping — Every application, what directory it authenticates to, what service accounts it uses, what happens if those service accounts are unavailable.
3. Trust relationship dependency map — Every trust relationship, what applications use it, what data flows across it, what breaks if it’s removed.
4. GPO dependency analysis — Every GPO that applies to both forests, what it controls, what breaks if it’s not applied post-migration.
Case Study: The 14-Month Forest Merger
A PE firm acquired a healthcare company with two AD forests. One was the production forest. One was a legacy forest from an acquisition 4 years prior that had never been fully decommissioned.
The discovery sprint post-close found:
- 47 service accounts in the legacy forest used by production applications
- 23 applications with authentication paths crossing the legacy forest boundary
- 4 federated authentication configurations in the legacy forest authenticating SaaS applications used by production
The merger timeline: 14 months (planned for 4 months). The budget overrun: £2.8M.
The discovery that would have changed this: a single AD FS configuration review in the legacy forest before signing.
ACQI runs AD merger discovery in 48-72 hours, with a complete dependency map and merger timeline estimate. Request an AD discovery sprint before your next integration.