AD forest consolidation with visible dependencies.
AD forest consolidation inventories the source, validates target mappings, dry-runs assumptions, and executes a bounded cohort with explicit reconciliation and rollback decisions.
Resolve the hard questions before execution.
BridgeAD supports the planning loop and provides controlled-pilot execution for agreed directory operations. Complex SID and rollback behavior remains topology-specific.
- Which source OUs and object classes are authoritative?
- Which target objects already exist or collide?
- How will UPNs, names, and parent OUs map?
- Which dependencies require ordered execution?
- Which SID history and ACL cases need lab validation?
- What constitutes a failed wave or rollback trigger?
- How will results be reconciled and approved?
- Which planned capabilities must remain out of scope?
What enters the first engagement.
Status is based on the current client-supported feature matrix and is confirmed against the release used for delivery.
Assess and prepare
Connections, discovery, mapping, CSV workflows, duplicate validation, and dry run.
Execute and recover
Migration orchestration, rollback, delta sync, SID history, ACL restamping, and password sync require scoped controls.
This requires topology-specific lab validation, elevated privileges, approved change controls, documented acceptance criteria, and rollback ownership before first client execution. It is not a universal or zero-touch capability.
Exclude from promise
Automated workstation rejoin, print queues, WMI filters, GPO security-filter translation, SMB/RoboCopy, and USMT.
Program prerequisites before execution.
These are agreed during the assessment phase and confirmed before any controlled-pilot execution.
| Area | Decision required |
|---|---|
| Identity authority | Which forest or domain is authoritative for each object class, and where each object will live after consolidation. |
| Trust posture | Whether forest trusts exist or must be established, and the trust direction required for the planned operations. |
| SID filtering | Whether SID history is in scope and how SID filtering between forests is configured. |
| Privileges | The approved privileged accounts and network paths the execution agent may use on each side. |
| Change control | Approved change windows, freeze periods, and the acceptance criteria that gate each cohort. |
| Rollback ownership | A named owner and a tested rollback path before the first irreversible operation. |
A bounded sequence, cohort by cohort.
Discover
Inventory source objects, OUs, and policy scope; surface collisions and dependencies.
Map
Build and validate source-to-target mappings, UPN and naming rules, and parent OUs.
Dry-run
Validate assumptions and conflict checks without changing the target.
Pilot
Execute a bounded cohort under controlled-pilot gates with rollback ownership.
Reconcile
Reconcile outcomes, record exceptions, and approve before the next cohort.
Common consolidation questions.
Do I need SID history for a forest consolidation?
Not always. SID history preserves access to resources that still reference old SIDs, but it is a controlled-pilot capability that requires lab validation and SID-filtering review. See the SID history migration guide for the decision criteria.
Is forest consolidation a zero-touch migration?
No. Discovery, mapping, and dry runs are supported; object execution, SID history, ACL restamping, and rollback are a controlled pilot requiring lab validation, change control, and named rollback ownership.
How is a failed cohort handled?
Each cohort runs under agreed acceptance criteria. A failed wave triggers the documented rollback or remediation decision owned by the named rollback owner before the next cohort proceeds.
Start with one representative cohort.
Choose objects that expose real mapping and permission risk without making the first execution irreversible.