Active Directory forest migration with ADMT — a roadmap (Part 1)

Introduction: why do you need a new forest?

Almost every organization with more than ten years of IT history has an Active Directory that still shows the fingerprints of several generations of admins: messy OUs, unused GPOs, dozens of unknown service accounts, and a domain that still carries the previous company name. Sometimes the main reason for a move is rebranding, a change of organization name, or irreversible damage that older services have done to the Schema.

Your domain controllers are also likely still on versions such as Windows Server 2012 or 2016 — operating systems whose support has already ended, or will end completely in the years ahead. The organization’s authentication core is standing on infrastructure that is officially past its security life, or getting there.

In that situation, an in-place upgrade looks like the first answer. That path inherits every piece of earlier technical debt (orphaned objects, old ACLs, and a poor structure). It is also a one-shot process: slow, and with no real rollback.

Microsoft’s official way to fix this at the root is Active Directory forest migration. Instead of rebuilding inside the same forest, you stand up a new, modern environment and move objects in phases, without a service outage. This series walks that transfer from start to finish, in operational terms.

Why a new forest instead of an in-place upgrade?

When the goal is rebuild and repair, not merely a Windows version bump, a new forest is the only logical choice.

The standard migration tool: ADMT

Microsoft’s official, free tool for this scenario is ADMT (Active Directory Migration Tool).

• The last version is 3.2.
• It needs a SQL Server database to store migration data (Express is enough).
• To move user passwords it needs a separate component, PES (Password Export Server), installed on a source domain controller (this capability has problems on Windows Server 2025).

Technical note: Microsoft has not updated ADMT after 3.2, and that release was officially supported up to Windows Server 2008 R2. In real projects, the same version still runs on Windows Server 2019, 2022, and even 2025 when compatibility prerequisites are met.

Three ideas you need before the project starts

The whole migration project rests on three pillars:

1. Forest Trust

Before any object can move, you need a trust (usually a two-way external trust or a forest trust) between source and target. That trust is the bridge ADMT uses to pass data. For the migration to work, SID Filtering on that trust has to be turned off temporarily.

2. SID History (access without an outage)

When a user is moved to the new forest, they receive a new security identifier (SID). If you stop there, they lose their previous access to file servers and applications.

The answer is the sIDHistory attribute. ADMT stores the old identifier on the new account. When Windows evaluates access, it reads that history and the previous permissions stay in place.

3. Security Translation

When computers and servers move, local resource permissions (local files, the registry, and user profiles) have to be translated from the old SID to the new one. ADMT’s Security Translation does that automatically so the user signs in to the new domain with the same desktop and profile as before.

Operational roadmap: migration in 8 phases

This is the path we will follow phase by phase in the rest of the series — and the order matches the official Microsoft documentation: