Domain Migration in Windows

— ny_wk

Domain migration in Windows moves user accounts, groups, and computers from a source Active Directory domain into a target domain, using the Active Directory Migration Tool (ADMT) to copy the SID History so users keep access to their old resources. This guide walks through the full migration flow end to end: prerequisites, the trust and SID-history setup, migrating users and computers, the agent-driven domain re-join, and how to verify that profiles, permissions, and logon all survived the move.

The classic mistake during a domain migration is treating it as a simple "unjoin and rejoin." Doing that orphans every NTFS permission, breaks roaming and local profiles, and forces users to reconfigure mailboxes, mapped drives, and applications. ADMT exists precisely to avoid that pain by carrying the user's original security identifier (SID) into the new domain.

What ADMT Does and Why SID History Matters

Every Active Directory object has a unique SID. File and folder permissions, mailbox rights, and group memberships are all stamped with SIDs, not usernames. When you create a brand-new account in a target domain, it gets a brand-new SID, so all of that old access evaporates.

ADMT solves this by writing the source account's SID into the sIDHistory attribute of the new target account. Windows treats every SID in sIDHistory as if it were the user's primary SID during access checks, so the migrated user can reach old resources while you slowly re-permission everything to the new domain at your own pace.

ADMT can migrate three object types, and a real domain migration in Windows usually runs all three in order:

• User accounts — copies users (and optionally passwords, via the Password Export Server) with SID History.
• Groups — migrates security groups and their membership so authorization survives.
• Computers — deploys an agent that re-ACLs the local machine, then re-joins it to the target domain. This is what actually moves the workstation.

Prerequisites Before You Start the Domain Migration

Migrations fail at the agent step far more often than at the wizard step, and almost always because of network, DNS, or service prerequisites. Confirm all of the following before touching ADMT.

On the migration (ADMT) server

• ADMT is installed on a member server or domain controller in the target domain, signed in with an account that is a domain admin in both domains (or has explicit delegated rights).
• A two-way trust (or at minimum the correct one-way trust) exists between source and target domains, and name resolution works both ways.
• SID History migration is enabled: the source domain must allow it. On the source PDC emulator, auditing of account management is on, and the target domain's <target>$$$ local group exists (ADMT creates it).
• If you are migrating passwords, the Password Export Server (PES) is installed on a source-domain DC with a key generated by ADMT.

On each user's PC (the client end)

1. Have the user save and close all open files on the desktop/laptop — the machine reboots automatically during the agent run.
2. Confirm these services are set to start and are currently Running: Server (LanmanServer), Netlogon, Workstation (LanmanWorkstation), and Remote Registry. ADMT pushes its agent over these channels.
3. Add the target-domain admin account to the PC's local Administrators group so the agent can install. Run: net localgroup administrators Company\DomainAdmin /add
4. Point the PC's DNS server to a target-domain DNS server (in the source material this is 172.20.50.9) so the machine can find and join Company.com.
5. Know a working local administrator credential for the PC — you will need it to rejoin and to log in after the move. Reset it if unknown.

Tip: verify the services quickly from an elevated PowerShell prompt: Get-Service Server, Netlogon, Workstation, RemoteRegistry | Select Name, Status, StartType. Start any that are stopped with Start-Service RemoteRegistry.

Step 1: Migrate User Accounts and Groups

Always migrate groups first, then users (or use the User Account Migration Wizard with the option to migrate associated groups), so that group memberships resolve correctly in the target domain.

1. Open ADMT on the migration server and launch the Group Account Migration Wizard. Select the source domain and the groups to move, choose the target Organizational Unit (OU), and enable Migrate SID History.
2. Launch the User Account Migration Wizard. Select the source users, the same target OU, and tick Migrate user SIDs to target domain and Migrate associated user groups.
3. If using PES, choose Migrate passwords; otherwise set Complex passwords and distribute them, or require a reset at next logon.
4. Set the conflict-handling option (do not migrate, or merge) and run the wizard. Review the migration log for any account that did not copy.

At this point the user objects exist in the target domain with their old SIDs preserved — but the workstation still belongs to the source domain. The computer migration in the next step is what actually relocates the machine and remaps the local profile.

Step 2: Run the Computer Migration Wizard (Server's End)

This is the core of the domain migration in Windows for each workstation. ADMT pushes an agent that translates local security (re-ACLing the registry, file system, profiles, and local groups to the migrated accounts) and then re-joins the machine.

1. In ADMT, open the Computer Migration Wizard.
2. Add the computer name to be migrated (you can add several to batch the run).
3. Select the correct destination OU in the target domain.
4. On the Translate Objects page, select what to translate — typically User Profiles, Local Groups, Files, Registry, and User Rights — and choose Replace mode so old permissions are swapped for the new account.
5. Choose Run pre-check and agent operation, then click Start.
6. On screen the Pre-Check should report PASSED. The agent operation then runs for roughly 15–20 minutes. When it finishes, the user's computer reboots automatically.

If the pre-check fails, it is almost always one of the prerequisites above — a stopped service, the firewall blocking the agent, wrong DNS, or the target admin not in the local Administrators group. Fix the flagged item and re-run; ADMT is safe to re-run.

Step 3: Rejoin and Log In (User's End)

After the automatic reboot, finish the move from the workstation. Some environments have ADMT perform the domain join automatically; if it does not, do it manually with the local administrator profile.

1. Log on with the local administrator account.
2. Open System > Domain or workgroup (or run sysdm.cpl), choose to join the domain, and enter Company.com. Authenticate with a target-domain account when prompted, then click Yes / OK.
3. Reboot the computer when asked.
4. At the logon screen, sign in with the migrated credentials: Company\username and the user's password.
5. Confirm the desktop, files, and shortcuts load from the original profile — ADMT mapped the existing local profile to the new account, so it should look identical. Finish.

Quick command-line domain join (optional)

You can script the join instead of using the GUI from an elevated PowerShell prompt:

1. Add-Computer -DomainName "Company.com" -Credential (Get-Credential) -Restart
2. After reboot, verify membership: (Get-WmiObject Win32_ComputerSystem).Domain

Common Pitfalls in a Windows Domain Migration

• Skipping SID History. If you forget the Migrate SID History checkbox, users lose access to old file shares and mailboxes the instant they log into the new account. Re-run the user wizard with SID History enabled to fix it.
• Wrong DNS on the client. A PC pointing at the source DNS cannot locate the target domain controllers, so the join silently fails. Always set DNS to the target DC first.
• Stopped Remote Registry or Server service. The ADMT agent cannot deploy, and the pre-check fails. Set them to Automatic and start them before the run.
• Firewall blocking the agent. File and Printer Sharing plus Remote Service Management must be allowed inbound. On a workgroup-isolated machine, temporarily enable the relevant firewall rules.
• Time skew. Kerberos fails if the client clock differs from the DC by more than five minutes. Sync time before migrating.
• Migrating users after computers. If the user account does not exist in the target domain when the computer agent runs, profile translation has nothing to map to. Migrate users (and groups) first.
• Treating it as unjoin/rejoin. A manual leave-and-join with no translation creates a brand-new profile (username.Company) and abandons the old one. Let ADMT translate the profile instead.

Step 4: Verification — Confirm the Migration Worked

Do not consider any machine "done" until you have verified identity, profile, and access. Run these checks while logged in as the migrated user.

• Account and domain: run whoami — it should return company\username. Confirm domain membership with (Get-WmiObject Win32_ComputerSystem).Domain.
• SID History present: on a DC, run Get-ADUser username -Properties SIDHistory | Select SIDHistory — the old domain's SID should be listed.
• Profile mapped, not recreated: the user's documents, desktop, and app settings appear as before, and only one profile folder exists for them under C:\Users (no duplicate like username.COMPANY).
• Resource access: open a previously mapped network share or mailbox and confirm it opens without a permission prompt — proof that SID History is doing its job.
• Group membership: run whoami /groups to confirm the user lands in the expected target-domain groups.
• Logon health: check the System and Application event logs for Netlogon or Group Policy errors, and run gpresult /r to confirm target-domain GPOs are applied.

Once every workstation is verified and you have re-permissioned shared resources to the new accounts, you can plan to remove SID History and eventually decommission the source domain — the final milestone of the project.

A Note on ADMT's Current Status

ADMT is a mature, free Microsoft tool that remains widely used for on-premises Active Directory consolidations and acquisitions. However, Microsoft has not released a major new version in years, and the latest build (ADMT 3.2) was designed for older server generations. It works on modern Active Directory in practice but is sensitive to OS and SQL prerequisites, so test it in a lab against your exact server versions first.

If your migration involves Entra ID (Azure AD), Microsoft 365, or cloud-joined devices, ADMT is the wrong tool — those scenarios use Entra Connect, cross-tenant synchronization, or dedicated third-party migration suites. ADMT is purely for on-premises domain-to-domain moves of users, groups, and computers, which is exactly the scenario this guide covers.

Key Takeaways

• ADMT performs domain migration in Windows by copying the source SID into SID History, so migrated users keep access to old resources.
• Order matters: migrate groups, then users, then computers — computer profile translation needs the target accounts to already exist.
• Most failures are prerequisite issues: client DNS pointing at the target DC, the four required services running, and the target admin in the local Administrators group.
• The Computer Migration Wizard pushes an agent that re-ACLs the profile and reboots the PC; the user then logs in as Company\username with the same profile intact.
• Always verify with whoami, SID History, profile integrity, and resource access before calling a machine migrated.

Frequently Asked Questions

Will users lose their files and profile during a domain migration?

No — when you use the ADMT Computer Migration Wizard with profile translation enabled, the existing local profile is re-mapped to the new domain account. The user logs in as Company\username and sees the same desktop, documents, and settings. Files are only lost if you skip ADMT and manually unjoin/rejoin, which creates a fresh empty profile.

What is SID History and why is it critical?

SID History stores the user's original security identifier on the new account. Because NTFS permissions, mailboxes, and group rights are tied to SIDs rather than usernames, SID History lets a migrated user access all their old resources immediately, giving you time to re-permission everything to the new domain before retiring the source.

Why does the ADMT pre-check fail with an agent or RPC error?

Almost always a client-side prerequisite: the Remote Registry, Server, Workstation, or Netlogon service is stopped; the firewall is blocking File and Printer Sharing / Remote Service Management; the client DNS still points at the old domain; or the target-domain admin is not in the PC's local Administrators group. Fix the flagged item and re-run — ADMT is safe to repeat.

Can ADMT migrate passwords too?

Yes, but only if you install the Password Export Server (PES) on a source-domain domain controller with an ADMT-generated key. With PES in place, the User Account Migration Wizard can copy passwords; without it, you must set complex passwords or require a reset at next logon.

For more hands-on Windows and system administration walkthroughs, subscribe to @explorenystream on YouTube.