An Active Directory frozen for twenty-two years, migrated to Windows Server 2025 without touching a single workstation

An Active Directory born under Windows 2000 or 2003 can be taken all the way to Windows Server 2025 without starting from scratch, provided the original forest is kept. That is what we did recently for a client whose directory had never been modernised: the domain kept its historical SID, Windows profiles and access rights stayed valid, and not a single client workstation was touched. Here is the starting point, what makes this kind of migration possible, and why it cannot be shortened.

The starting point: a frozen directory, still very much alive

When we took the file over, the directory was working. It simply carried twenty-two years of history without ever having been modernised. The initial survey showed:

• forest and domain functional levels still at 2003, the oldest compatibility baseline Active Directory can still present;
• a SYSVOL still replicated by FRS, the original replication mechanism, dropped by Microsoft in favour of DFSR;
• two domain controllers, one of them running Windows Server 2003.

None of this shows in day-to-day use. A directory in that state keeps opening sessions and handing out rights without making a sound, which is why it can go through two decades without anyone paying attention to it. The problem only appears the day you need to add a recent server, meet a security requirement or replace a machine at the end of its life.

Keeping the forest means keeping the SIDs

The client’s requirement was clear: keep the existing forest, and with it the domain SID and the user SIDs. This is not a purist’s whim, it is what decides how much work lands on the estate.

A SID (Security Identifier) is the internal, unique and permanent identifier Active Directory assigns to the domain and to every account. It is the SID, not the user name, that Windows writes everywhere: in the local profiles on workstations, in the NTFS permissions of file shares, in the rights applied to business applications.

Creating a brand new domain, even with the same account names, would have produced new SIDs. The consequence is very concrete: every workstation would have had to be removed from the old domain and joined to the new one, every user profile recreated or migrated, every share permission reapplied. In other words, someone would have had to visit every machine on the estate, with the lost time and the irritation that implies for the teams. By keeping the forest, the workstations saw nothing: the domain beneath them changed generation, their session did not.

Why a double hop was unavoidable

You do not go from a directory at the 2003 level to a Windows Server 2025 domain controller in a single operation. Four constraints interlock, and none of them can be worked around:

• a Windows Server 2025 domain controller requires forest and domain functional levels of at least 2016;
• a 2016 level requires every domain controller to run 2016 or later, hence the need for an intermediate controller;
• Windows Server 2019 and later refuse to promote a controller while SYSVOL is still replicated by FRS;
• the tool that migrates SYSVOL from FRS to DFSR requires a domain level of at least 2008.

In other words, FRS has to be dealt with before a recent server can be installed, the domain level has to be raised before FRS can be dealt with, and a transition controller has to be brought in before the target can be reached. The sequence cannot be reordered: the directory has to go through two intermediate generations before reaching 2025, each step unlocking the next.

What sets the duration: the chain, not the size of the domain

This is the most useful thing to remember if you are in the same situation. The duration of such a migration comes from the length of that chain, not from the number of users. Twenty accounts or two thousand, it is the same steps, the same replication waits, the same checks between each one.

Many organisations are surprised by the gap between the size of their estate and the amount of work announced. That is the explanation, and it can be verified: every step is imposed by Microsoft, and each one has to be validated before moving on to the next. It is also what makes the operation predictable. Before starting, we can say what will be done and in what order, what will be scheduled outside business hours, and what has no visible impact on users at all.

What the client gains

Beyond leaving behind a software baseline that has been out of support for a long time, a modernised directory brings immediate benefits:

• complete continuity for users: same accounts, same passwords, same profiles, same rights on the shares, no work on the workstations;
• reliable SYSVOL replication with DFSR, more robust and far more sparing with bandwidth than FRS, which matters as soon as the domain spans several sites;
• the foundation for the modern security features of Active Directory, out of reach at the 2003 level, and compatibility with current monitoring and backup tools;
• a directory that is documented and monitorable again, with a clear recovery plan should a controller be lost.

We do not stop at the migration

A successful migration means a directory that comes back up cleanly. It does not yet mean a healthy directory. Twenty-two years of existence leave traces: accounts nobody can put a name to any more, service accounts created for software that has since disappeared, administrative rights granted for the duration of one fix and never taken back, passwords that never expire, group policies still applying to machines that were scrapped long ago.

We do not do the job halfway. Once the migration is complete, we review the whole picture: user and service accounts, membership of the administrative groups, rights delegated on the directory, roles and services installed on the servers, group policies, and the backup and restore plan for the directory itself. Whatever is no longer used is disabled and then removed, whatever stays is documented, and the whole is hardened: privileges brought back to what is strictly necessary, unnecessary services stopped, logging and monitoring in place.

That is often the moment when the client sees the real value of the operation. They do not simply get a supported directory back: they get a directory whose contents they know.

If your directory is in the same state

Three signs are enough to tell whether this concerns you: a domain controller running a version of Windows Server older than 2016, a functional level never raised since the original installation, or a SYSVOL still replicated by FRS. These situations are common, including in organisations whose information system is otherwise perfectly up to date, precisely because the directory is the component that keeps working without anyone looking at it.

IT1 Connect carries out this kind of migration for SMBs, mid-sized companies and public authorities across the PACA region: an initial survey of the forest and its functional levels, a step-by-step migration plan, execution scheduled outside production hours, then managed services and monitoring of the directory over time. The goal we set ourselves is always the same: your users have nothing to do, and nothing to notice. To review your Active Directory with an engineer who already knows your environment, get in touch.