Migration and upgrade planning

Choose the kind of change

Replacing domain controllers in an existing domain, moving accounts between domains, and creating a new forest have different consequences. Write down which boundary is changing before choosing a tool.

The public ADMT 3.2 migration guide (Word document) describes interforest user and group migration as a copy: the source object remains and the target receives a new identity. Intraforest user and group migration is a move: the source location no longer contains the original account. These distinctions determine what rollback can mean. Computer and managed service account handling has additional differences; do not generalize the user-account rule to every object class.

ADMT is historical tooling

ADMT’s planning model remains useful, but a successful lab installation does not establish support for a modern migration. Microsoft has deprecated the ADMT 3.2 code base, halted development and excluded it from security fixes, bug fixes and design changes. Support is on a best-effort basis. The support article also documents modern profile and security-default incompatibilities. Check the exact source, target, agent and SQL versions before selecting tooling. ADMT support policy.

If the tool needs protections weakened to run, work through that decision before choosing it. Know what will be exposed and test how those protections will be restored. Don’t carry old prerequisites onto current DCs just because they appear in a migration guide.

The current support statement explicitly says ADMT has not been updated for Windows 10/11 or the listed newer server releases. It documents incompatible profile behavior and dependencies that can conflict with Credential Guard, LSA protection and TLS settings. The 2014 guide’s historical platform language and later download-page publication date do not supersede that support statement. Validate the entire migration path, including agent and SQL requirements, before selecting a tool.

Inventory dependencies before accounts

Record the source and target OU, account name, UPN, groups, owner and migration batch. Find name conflicts and decide whether an existing target object should be merged, renamed or excluded. Keep the mapping; you’ll need it to investigate failures and reverse changes.

Resource access is usually the longer list. Include file and share ACLs, local groups, services, scheduled tasks, applications, database logins, logon scripts, certificates and user profiles. An account that can sign in may still be unable to do its job.

Service accounts need their own inventory. Find every consumer of the identity, its SPNs, delegation settings, logon rights and password-change procedure. Moving an account won’t update every service configuration. Check how the tool handles managed accounts too; a historical sMSA workflow won’t cover every account type.

For an existing domain, these RSAT queries capture a useful starting point:

Get-ADForest | Select-Object Name, ForestMode, Domains, SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object DNSRoot, DomainMode, PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADDomainController -Filter * |
    Select-Object HostName, Site, OperatingSystem, IsGlobalCatalog

The last two commands inspect the current domain. Repeat them against the intended domain or explicit DC when documenting a forest with several domains.

Capture the identity mapping for a pilot user before and after the change:

Get-ADUser -Identity 'pilot.user' -Server 'dc1.source.contoso.com' `
    -Properties sIDHistory,userPrincipalName |
    Select-Object DistinguishedName,SID,ObjectGUID,userPrincipalName,sIDHistory

Repeat against the target using the mapped target name. Names, GUIDs, SIDs, profiles, application identifiers and synchronized cloud anchors answer different questions. If directory synchronization is involved, plan source-anchor continuity with its own supported migration process; copying a group name is not that continuity. Microsoft documents cross-forest synchronized group migration separately.

SIDHistory and security translation solve different problems

An interforest target account has a different objectSID. SIDHistory can preserve the old SID as an additional authorization identity while resources still carry source-domain ACLs. Its effectiveness depends on the trust and SID-filtering configuration. Plan how the history will eventually be removed after dependencies have been translated and tested.

SIDHistory grants access, so audit both its population and removal. The SIDHistory API description explains the authorization consequence. Check what the migration actually requires before weakening trust filtering.

Security translation changes security descriptors or related local settings to refer to target identities. Historically, ADMT offered modes with different rollback consequences:

Record which resources and profiles were translated and in which mode. An additive translation can preserve a path back to the old identity; a replacement requires a tested reverse mapping. Neither SIDHistory nor translating file ACLs proves that profile state and applications will work.

Include encrypted user data in the pilot. An EFS file needs a matching decryption key or a recovery agent recorded in its encryption metadata; target SIDHistory and a translated NTFS ACL do not supply that key. Test old files under the migrated profile with the intended private-key recovery path before removing source profiles, accounts or backups. See EFS recovery evidence.

Group scopes can determine the migration batch

For an intraforest move, model memberships that become invalid when an account changes domain. A global group accepts accounts and global groups from its own domain; moving a user alone can therefore break the intended membership path. Domain-local groups have another constraint: their permission scope is their own domain. Microsoft’s group-scope table distinguishes membership from where a group can grant access.

Draw the dependency before defining the batch: user → global group → resource-domain local group → resource ACL. Work out which users, nested groups and resources cross a domain boundary at each stage. This is why older migration guidance calls for a closed set of related accounts and groups. Converting everything to universal scope creates its own work: permitted nesting, foreign principals, replication and the target authorization context still need checking.

Test the access path during the intermediate state as well as after the final move. A design that is valid after every account has moved can still fail halfway through a phased migration.

Passwords and coexistence

ADMT uses Password Export Server for interforest password migration. That is separate from copying the user object. Test password handling explicitly, including what happens when users change passwords during coexistence. Current Microsoft documentation describes conflicts between PES and LSA protection; copying historical setup instructions is insufficient. Known ADMT issues.

Choose where account and group changes will be made during each phase. Check which attributes a repeated migration overwrites and which group memberships it merges. Otherwise an administrator can make a valid target-side change only to have the next migration pass replace it.

Pilot the complete working day

Use a representative test user, groups, workstation and application dependencies. Test the source experience first, then repeat the same checks with the target identity after account migration, profile handling and computer migration.

Check interactive sign-in, file and print access, application authentication, user data, desktop state and background services. Restart the workstation and the affected services. Test both retained source resources and migrated resources, including access through nested groups.

Set the stop condition before the batch starts: the failure rate, user impact or elapsed outage that triggers rollback. Increase batch size only after the complete pilot passes. The ADMT 3.2 guide states that the tool has no test-migration option; a production pilot makes real changes. Include certificate authentication in the pilot: a credential bound to the old account SID can require reissuance or supported strong mapping for the target identity.

Make rollback concrete

For an interforest account copy, returning to the source may require re-enabling the source account, signing out of the target, returning computer membership, repairing profile access and checking resources. Retaining the source object is only part of that procedure.

For an intraforest move, plan a migration in the reverse direction. Do not assume the source object is waiting to be re-enabled. Preserve mappings, logs, backups and the settings needed to reverse translated permissions. Define a separate finalization point for removing source accounts, trusts and SIDHistory.

Upgrade DCs in stages

Before changing the directory, check replication, DNS, SYSVOL, backups, role availability and application compatibility. Repeat the checks after each DC change. Applications also need testing against the new release’s LDAP, authentication and cryptographic behavior; the old DC’s operating-system feature list won’t tell you whether they’ll work.

Microsoft currently recommends promoting new servers from clean OS installations and demoting older DCs as needed. An in-place OS upgrade has its own supported paths and prerequisites. Schema preparation is integrated into new-DC promotion; an in-place DC upgrade requires the applicable adprep steps separately. DC upgrade guidance.

Keep OS replacement, schema preparation and functional-level changes distinct in the plan. Check the current interoperability matrix: Windows Server 2025 DCs support the Windows Server 2016 and 2025 functional levels. Adding a 2025 DC does not itself require raising the forest to the 2025 level. Functional levels.