Migrate as planned
Clean objects with resolved mappings, no collisions, and no blocking dependencies.
Checklist
The Active Directory migration checklist.
A cross-forest Active Directory migration fails in the gaps between phases, not inside them. This checklist sequences the work — discovery through decommission — so each phase produces the evidence the next one depends on.
How to use thisTreat every unchecked item as an open risk with an owner and a date. A checklist without named owners is a wish list.
Phase 1
Discovery and inventory.
Everything downstream is scoped from this baseline. Run it read-only and keep the output.
- Inventory forests, domains, trusts, sites, domain controllers, and functional levels
- Enumerate users, groups, computers, service accounts, and their enabled/stale status
- Capture group nesting, primary group membership, and cross-domain memberships
- Record DNS zones, delegation, conditional forwarders, and name-resolution paths between source and target
- Identify applications, services, and scheduled tasks bound to domain identities (LDAP paths, SPNs, hard-coded domain names)
- Document GPOs in force and which migrating objects they affect
Phase 2
Assessment and risk classification.
Convert the inventory into decisions. Each object or dependency should land in exactly one bucket.
Needs a decision
Duplicates, ambiguous matches, disabled-but-referenced accounts, or objects with unclear ownership.
Fix before migration
UPN collisions, broken ACL inheritance, orphaned SIDs, stale trusts, or application hard-coding.
Explicitly out of scope
Objects excluded by business decision, recorded so nobody assumes they moved.
Phases 3–5
Mapping, prerequisites, and dry run.
This is the half of the project that determines whether execution is boring — which is the goal.
- Build object mappings (CSV or rules) with duplicate detection and target-side validation
- Decide UPN and sAMAccountName strategy for collisions before they surface mid-wave
- Verify trust configuration, SID filtering posture, and whether SID history is required (see the SID history guide)
- Confirm password migration approach and its security approval
- Validate network reachability, ports, and name resolution from the migration infrastructure to both directories
- Run a dry run over the full planned scope; review every planned change and each detected conflict
- Freeze the scope: additions after this point re-enter through assessment
Phases 6–8
Pilot, staged execution, and validation.
Never scale a wave pattern that has not survived a representative pilot with defined acceptance criteria.
- Select a pilot wave that exercises real dependencies: nested groups, ACL-protected resources, one line-of-business application
- Define acceptance criteria and rollback ownership in writing before the pilot starts
- Validate sign-in, resource access via SID history or restamped ACLs, and application behavior after the pilot
- Sequence remaining waves by dependency, not alphabet — resource domains after account domains, applications after their identities
- Run delta passes for changes that landed after the initial copy
- Reconcile every wave: object counts, membership integrity, ACL spot checks, and skipped-item disposition
Phases 9–10
Rollback readiness and decommission.
The migration is finished when the old forest is safely gone — not when the last wave completes.
- Document per-operation reversibility: what rolls back automatically, what needs a runbook, what is one-way
- Keep the audit trail and reconciliation exports; they are the evidence for security review and the input for decommission approval
- Monitor authentication against the source domain to catch lingering dependencies before trust removal
- Remove SID history and tighten SID filtering once resource access is fully re-permissioned
- Decommission trusts, DNS forwarding, and source domain controllers in that order, with a pause between steps
Run this checklist against your actual forest.
A BridgeAD readiness assessment executes phases 1 and 2 for you — read-only discovery, findings, mappings, and a recommended pilot boundary you can take to change control.