How to Plan a Zero-Downtime Active Directory Migration

The Core Challenge

An Active Directory migration that goes wrong affects every user, every application, and every service in your organization simultaneously. That’s why planning is everything — not just the technical steps, but the sequencing, the communication, and the rollback strategy.

After migrating more than 75,000 user accounts across dozens of projects, here is the framework I follow for every AD migration.

Phase 1: Environment Assessment

Before writing a single migration script, spend time thoroughly documenting what you’re working with:

• Forest and domain structure — single forest? Multiple? Trust relationships?
• Object inventory — how many users, groups, computers, service accounts, GPOs?
• Applications with AD dependencies — which apps authenticate against AD? Do they use Kerberos, NTLM, LDAP?
• Service accounts — which services run as domain accounts? This is often underestimated.
• SID history requirements — will migrated accounts need access to resources in the source domain post-migration?

Tools I use: Active Directory Users and Computers, PowerShell (Get-ADUser, Get-ADComputer, Get-ADGroup), and ADRecon for automated inventory.

Phase 2: Target Environment Design

Don’t start migrating until your target environment is fully built and validated:

• New domain/forest with correct functional level
• DNS forwarding between source and target
• Trust relationships established
• Baseline GPOs deployed
• File server and application access tested with test accounts

Run a test migration of 10–20 non-production accounts first. Validate:

• Login works on domain-joined machines
• Access to shared drives is intact
• Applications authenticate correctly
• Email (if Exchange is involved) delivers correctly

Phase 3: SID History Strategy

SID history is critical for preserving access to resources in the source domain after migration. If users migrate to a new domain but still need to access file shares, printers, or applications in the old domain, their SID history must carry forward.

# Example: Migrate user with SID history using ADMT
Move-ADObject -Identity "CN=JohnDoe,OU=Users,DC=source,DC=local" `
              -TargetPath "OU=Users,DC=target,DC=com"

Important: SID history migration requires the source and target domains to have a trust, and requires the SidHistory attribute to be enabled on the target domain. Always test this with non-critical accounts first.

Phase 4: Migration Waves

Never migrate all users at once. Structure migrations in waves:

1. Wave 0 — Pilot (IT staff only): 5–10 IT staff who can troubleshoot issues and validate the process.
2. Wave 1 — Low-risk departments: departments with simpler requirements, fewer application dependencies.
3. Wave 2–N — Remaining departments: migrate in logical groups, usually department by department.

Between each wave:

• Collect feedback
• Resolve any access issues before proceeding
• Update your runbook with lessons learned

Phase 5: Cutover and Decommission

Once all users are migrated and validated:

1. Remove trust relationships
2. Decommission source domain controllers (don’t just shut them off — follow the proper FSMO role transfer process)
3. Clean up DNS records
4. Archive the old environment for a minimum 90-day retention period before decommission

What Goes Wrong (and How to Avoid It)

Final Thoughts

A zero-downtime AD migration is achievable, but only with rigorous planning. The migration itself is the easy part — it’s the assessment and the testing that determine success.

If you’re planning an Active Directory migration and want a specialist to review your plan or lead the execution, get in touch.