Learn Active Directory - Active Directory Migration

#Introduction

In episode 24 we tuned performance: baselines, hardware sizing, LDAP query optimization, and database defragmentation. After your DCs run fast, a more strategic question arises: how do we move an entire organization's identities to a new structure — a new domain, new forest, or a consolidation result — without stopping the business?

AD migration is one of the riskiest operations in the identity world. AD is the authentication source: if the migration fails halfway, no user can log on, applications lose sessions, and management panics. The key isn't courage, but planning, the right tools, and a rollback path always ready. Let's dissect the process from start to finish.

#Why AD Migration Is Risky

The root problem is simple: resources in Windows are secured by SIDs, and those SIDs are tied to the domain. When a user moves to a new domain, they get a new SID — and every ACL referencing the old SID becomes invalid. That's where the risk lives:

• File and folder ACLs store old SIDs; a user moves domains but loses access.
• GPOs, scripts, and service accounts often reference domain names or SIDs explicitly.
• Legacy applications can hardcode domain names or UPNs.

A good migration answers three questions: how to move objects, how to preserve access, and how to back out if something goes wrong.

#Phase 0: Inventory and Planning

Don't move anything before you know what you own. The inventory must cover users, computers, groups, OUs, GPOs, trusts, service accounts with their SPNs, and Exchange if present. PowerShell is the fastest inventory tool:

Get-ADUser -Filter * -Properties Enabled, LastLogonDate, Department |
    Select-Object SamAccountName, UserPrincipalName, Enabled, LastLogonDate, Department |
    Export-Csv -Path "C:\Data\inventory-users.csv" -NoTypeInformation -Encoding UTF8
 
Get-ADComputer -Filter * -Properties OperatingSystem, LastLogonDate |
    Select-Object Name, OperatingSystem, LastLogonDate |
    Export-Csv -Path "C:\Data\inventory-computers.csv" -NoTypeInformation -Encoding UTF8

Also document dependencies: which servers use which accounts, which applications need AD integration, and who is the business owner for each group of users. Those business owners are the ones who'll validate migration results later.

#Choose a Strategy: Upgrade, Intra-Forest, or Inter-Forest

The strategy is determined by starting conditions and the end goal:

• In-place upgrade. The same domain is upgraded to a new functional level. Simplest, no new SIDs, but doesn't fix already-wrong design problems.
• Intra-forest migration. Moving objects between domains within the same forest (restructure). Parent-child trust is automatic; SID History is optional for preserving access.
• Inter-forest migration. Moving between forests (forest consolidation, acquisition, integrating two companies). Requires an external or forest trust, ADMT, SID History, and password migration.

For simple intra-forest restructuring, Move-ADObject is enough to move users and computers between OUs or domains.

#Prepare DNS and Trust

#DNS First, Then Trust

Cross-domain migration requires two-way name resolution. Add a conditional forwarder so the old DC can resolve the destination domain name (and vice versa):

dnscmd dcold /ZoneAdd corpnew.local /Forwarder 10.0.2.20

#Building the Trust

Once DNS is settled, create the trust. For inter-forest use a forest trust; for a single domain an external trust is enough. Watch the trust direction: a one-way trust is enough to read source data, a two-way trust eases mutual authentication. Choosing selective authentication prevents users from another domain from misinterpreting their rights:

New-ADTrust -Name "corpnew.local" `
    -TargetForest "corpnew.local" `
    -Direction Bidirectional `
    -TrustType Forest `
    -UsesAESEncryption $true

#ADMT: The Main Migration Tool

Active Directory Migration Tool (ADMT) 3.2 is Microsoft's tool for inter-domain and inter-forest migration. It handles users, groups, computers, service accounts, and Exchange while preserving account properties. Three concepts you must understand:

• Agent on DCs. ADMT needs an agent installed on source and destination DCs for certain operations.
• Password migration. Password migration never stores plaintext. For inter-forest, a Password Export Server (PES) moves hashes one-way from the source domain.
• SID History. The most important and simultaneously most risky feature.

#SID History: The Key to Access, and a Risk

When a user is migrated, ADMT writes the old SID to the new account's sIDHistory attribute. As a result, all ACLs referencing the old SID stay valid — the user seemingly never moved. This is why migration can run smoothly without changing a single file permission.

But sIDHistory is a double-edged sword: if the source domain is compromised, SIDs from the source domain could be abused to access destination domain resources. Always enable SID filtering on the trust, and clean up sIDHistory after the verification period ends. Verify membership in the new account:

Get-ADUser -Identity "jsantoso" -Properties SIDHistory |
    Select-Object SamAccountName, SIDHistory

#Profile and User State Migration

Moving an account doesn't mean moving the account's contents. The profile — documents, desktop, application settings, and browser history — must be moved separately. The tool is the User State Migration Tool (USMT): scanstate captures, loadstate restores:

scanstate \\filesrv\migration\jsantoso /i:MigApp.xml /i:MigUser.xml /o
loadstate \\filesrv\migration\jsantoso /i:MigApp.xml /i:MigUser.xml /lac /lae

The /lac and /lae parameters create a local account and enable it — useful when restoring a profile before the user starts using the new domain account. For large organizations, USMT can run without user interaction via scripts and GPOs.

#Coexistence, Cutover, and Rollback

#Coexistence Period

Both environments run side by side for a period. SID History and trust keep cross-domain access working; email is redirected temporarily; GPOs are frozen so they don't change behavior mid-migration. Coexistence gives testing time without the pressure of an instant cutover.

#Phased Migration vs Big Bang

• Phased migration moves users in groups: a small pilot first, verification, then the next wave. Risk is contained and feedback comes early.
• Big bang moves everyone at once. Only suitable for small environments; one mistake means the entire organization is paralyzed at the same time.

#The Rollback Plan

Never start a migration without a way back:

1. Keep a full backup of the source domain's database and SYSVOL (episode 17).
2. Maintain the trust and SID History throughout the verification period.
3. Set written rollback triggers: e.g. "more than 10% of the pilot failing logon" means back out.
4. Don't decommission the old domain until verification is complete and management signs off on the results.

Cutover is the official moment of transition: DNS is redirected, logons are directed to the new domain, and the change is announced to users.

#Post-Migration: Cleanup and Verification

After cutover, the work isn't done. Verify first, then clean up:

• Test logon, file share access, GPOs, and applications from the new accounts.
• Confirm replication is healthy with no errors via repadmin /replsummary.
• After all access is verified, clean up SID History to close the security gap:

Get-ADUser -Filter * -Properties SIDHistory |
    Where-Object { $_.SIDHistory } |
    Set-ADUser -Remove @{ SIDHistory = $_.SIDHistory }

Finally, remove unneeded trusts and decommission the old domain with clean metadata cleanup (episode 6) — make sure no references remain.

#Conclusion

In episode 25 you learned the anatomy of AD migration: why SIDs make migration risky, inventory before moving, three strategies (upgrade, intra-forest, inter-forest), DNS and trust preparation, using ADMT with SID History and password migration, profile migration with USMT, the coexistence period, cutover with rollback, up to post-migration cleanup.

Key points:

• SIDs determine access; SID History preserves access, but must be cleaned up.
• DNS must be prepared before the trust; trust before migration.
• Pilot first, then subsequent waves — don't big bang large environments.
• Keep backups and rollback triggers; don't decommission before verification is complete.

Once the new environment stands, one question must be answered with confidence: what happens if everything collapses? In episode 26 we dissect Active Directory Disaster Recovery: RTO and RPO, system state backup, restoring a single DC up to a forest, and testing the plan before disaster strikes. See you there!