Windows Server upgrade and migration
An old server is rarely one thing. It’s often the domain controller, DNS and DHCP server, file server and print server at once, and the home of an application nobody has touched in years.
The upgrade itself is routine. Most of the work is finding everything that depends on the old server before it goes.
An older Windows Server, out of support
- Domain controller
- DNS and DHCP
- File shares
- Print server
- Accounts package
Breaks the morning after
- The copier scans to a share on it, over SMB1First scan of the day fails
- DHCP hands out its address as the DNS serverNothing resolves once it’s off
- A logon script maps S: to \\FS01\sharedMissing drive at sign-in
- Wi-Fi sign-in checks NPS on itLaptops can’t join the network
Breaks weeks later
- The switch relays DHCP requests to its addressFails as leases come up for renewal
- The accounts package licence is tied to its hostnameFails at the next licence check
- A scheduled task runs the month-end exportMissed at month end
- The backup job still points at its volumesFound when someone needs a restore
Most of a server migration is finding these before cutover. The rest is moving each one in the right order, with a way back.
Upgrade in place, or build new
Every version of Windows Server has a published end-of-support date, and security updates stop on that date. The decision for each server is which path to take.
Upgrade in place
Suits a server that:
- does one job, and that job isn’t domain controller
- runs software whose vendor supports the new version
- sits on hardware or a host that can run the new version
- is within a supported upgrade path from where it is now
- has a backup or snapshot that’s been proven to restore
Quicker, and everything stays where it is, including the clutter.
Build new and migrate
Suits a server that:
- is a domain controller: a new one is added and the old one retired, not upgraded
- has collected roles and software over many years
- is too many versions behind for a supported in-place upgrade
- is moving to new hardware or a different host anyway
- needs a fallback that stays intact until the client is satisfied
More planning, but the old server is left untouched, then switched off, ready if something surfaces.
Many jobs are both. An application server upgraded in place, and the domain controller beside it replaced. The plan says which path each server takes, and why.
Licensing changes either way. The new version needs its own core licences unless they’re covered by Software Assurance, and client access licences must match or be newer than the server version, so older CALs don’t carry across.
How each role moves, and where it goes wrong
Every role has a standard way to move. The trouble is usually in what was built around it.
Active Directory
A new domain controller is promoted beside the old one. Replication is confirmed healthy, the FSMO roles are transferred, and the old controller is demoted properly, never just switched off.
A domain still replicating SYSVOL with FRS won’t take a current domain controller until it’s moved to DFSR. Existing replication faults travel with the domain, so health is checked before anything is added.
The PDC emulator is the domain’s time source. Move the role, and the new holder needs its time source set.
DNS
Active Directory-integrated zones replicate to the new controller on their own. Forwarders, conditional forwarders and scavenging are set to match, then everything that names a DNS server by address is repointed.
DNS server addresses are typed in all over the place: DHCP options, servers and printers with static addresses, the firewall, VPN settings. Often the cleanest answer is to give the new controller the old one’s IP address once it has been demoted.
DHCP
Scopes, reservations, options and current leases are exported and imported together, so devices keep their addresses through the change. Any failover partnership is rebuilt on the new server.
Switches and firewalls relaying DHCP to the old server’s address. Devices hold their leases for a while, so nothing looks wrong until leases run out or a new device joins.
File shares
Data is copied ahead of time with its permissions, and a final pass picks up the changes at cutover. Share and NTFS permissions are compared, not assumed. Microsoft’s Storage Migration Service can carry the old server’s name and address across, so existing paths keep working.
Paths like \\FS01\shared live in logon scripts, Group Policy, application settings, Office templates and desktop shortcuts. Keeping the name, or putting the shares behind a DFS namespace, means the next migration doesn’t meet the same problem.
Printing
Queues, drivers and ports are moved with Windows’ printer migration tools, and printers deployed through Group Policy are pointed at the new server.
Older drivers may not exist for the new version. And since the PrintNightmare fixes, standard users can’t install printer drivers by default, so drivers are put in place before anyone connects.
Line-of-business applications
Installed and configured on the new server with the vendor where they need to be involved, including databases, services and the settings desktop clients use to connect. Then tested by the people who use them.
Vendors support particular Windows Server and SQL Server versions, not all of them. Licences can be tied to a hostname, MAC address or hardware, and some need the vendor to reissue them. Desktop clients often hold the server name in a config file or ODBC connection on every PC.
Everything nobody wrote down
Scheduled tasks, services running under named accounts, NPS for Wi-Fi and VPN sign-in, certificate services, SMTP relay for copiers and applications, backup and monitoring agents. Each one is found before cutover and given a plan of its own.
Current versions of Windows Server don’t install SMB1 by default, and some older copiers and scanners speak nothing else. These are the failures that surface weeks later, so we go looking for them before cutover.
The old server goes last
When the work is a move to a new server, nothing is taken away from the old one until its replacement has done the job.
-
Alongside
The new server is built, patched, joined to the domain and given the roles that can run in parallel, such as domain controller and DNS.
- Old server
- Running everything, unchanged
- New server
- Built and sharing the domain
-
Cutover
In the agreed window, the last data changes are copied, DHCP and printing move, names and addresses are repointed, and applications switch over with their vendors.
- Old server
- Still on, handing over
- New server
- Takes on files, print and apps
-
Proving
The client tests the way they normally work: signing in, opening files, running the application, printing and scanning. Anything that turns up is dealt with on the new server.
- Old server
- Switched off, intact: the way back
- New server
- Doing the whole job
-
Retired
Once the client is satisfied, the old server is demoted and removed from Active Directory, DNS, backup and monitoring, then wiped. Each step goes into the decommission record.
- Old server
- Demoted, removed and wiped
- New server
- Documented as built
An in-place upgrade is shorter but no less careful: a restore point that has been proven to work, then the upgrade, then the same testing with the client. If something won’t come right, the restore point is the way back.
What the client ends up with
Servers on a supported version
Upgraded in place or replaced, running the roles and applications they ran before, with the scripts, devices and settings that depended on the old server pointed at the new one.
A decommission record
What moved where, when the old server was demoted, which records were cleaned out of Active Directory and DNS, and when it came out of backup and monitoring and was wiped. The answer, in writing, when someone later asks what happened to it.
As-built documentation
The new servers, their roles, shares and permissions, application settings and vendor contacts, written for whoever looks after them next. That’s you.