Many companies still run servers that were set up years ago and “work fine for now.” But Microsoft sets an end-of-support date for every Windows Server version, and after that date new vulnerabilities are no longer patched; the server becomes a permanent weak spot in the network. Windows Server 2012 and 2012 R2 have been out of support for some time, and the end of support for 2016 is approaching. Check the exact date for each version on Microsoft’s Lifecycle page.
In-place upgrade or migration to a new server?
- In-place upgrade: The new version is installed on the same server, and applications and settings are kept. It seems faster, but direct upgrade paths are limited, and accumulated old problems and settings carry over to the new version.
- Migration: A fresh server is built with the new version, and roles are moved to it one by one. It takes longer, but it creates a clean environment, and the old server remains available for rollback until the work is done.
For most companies, migration is the safer option. For domain controllers in particular, the common, low-risk approach is to add a new controller and gradually retire the old one.
Step 1: A complete list of roles and dependencies
Before anything else, write down exactly what each old server does. There is almost always something nobody remembered:
- Roles: domain controller, DNS, DHCP, file server, print server, Remote Desktop
- Business applications: finance, office automation and databases
- Scheduled tasks, scripts and services that run under a specific user account
- Devices that rely on this server’s IP or name, such as scanners that save files to it
Ask each software vendor to confirm compatibility with the new Windows Server version.
Step 2: Prepare the infrastructure
- If the physical server is old, check hardware and driver support for the new version. This is usually the best opportunity to move the server to a virtual machine.
- Obtain licenses in advance; Client Access Licenses (CALs) must also match the new server version. Licensing details depend on your agreement type.
- Before starting, take full backups of all old servers and test restoring them.
Step 3: Migrate role by role
- Domain controller: Add the new server as a domain controller, confirm replication is healthy, transfer the FSMO roles, and point the DNS settings in DHCP and on your servers to the new controller. Then properly demote the old server rather than simply shutting it down.
- File server: Move the data while preserving permissions; Storage Migration Service in Windows Admin Center is designed exactly for this.
- DHCP: Export the scopes and reservations from the old server and import them on the new one.
- Applications: Follow the vendor’s instructions, usually a fresh install plus a database migration.
Once all the old domain controllers have been retired, you can raise the domain and forest functional levels.
Don’t wipe the old server immediately after migration. Keep it powered off and untouched for a few weeks so you have a way back if a forgotten dependency turns up.
Common mistakes
- Migrating every role in a single night with no rollback plan
- Forgetting devices and scripts with the old server’s address hard-coded in them
- Shutting down the old domain controller without demoting it, which leaves stale data in Active Directory
- Not telling users about possible service downtime
Checklist
- The list of roles, applications and dependencies is complete.
- Software and hardware compatibility has been confirmed.
- The required licenses have been obtained.
- Full, tested backups of the old servers exist.
- A rollback plan is written for every step.
- The old server is kept until the end of the validation period.
ITPlus724 engineers can assess your legacy servers, write a phased migration plan and carry out the move with minimal downtime for your users.