Windows Server upgrades: when and how

Server upgrades get deferred because the machine is working and the upgrade carries risk. Both observations are true. The problem is that the risk of waiting grows quietly while the risk of acting stays roughly constant.

The dates that should drive the decision

Two matter, and they are different.

Mainstream support end — no more feature updates, but security updates continue. Not urgent by itself.

Extended support end — no more security updates. From this date the server accumulates publicly documented, unpatched vulnerabilities indefinitely.

Past extended support you are not running an old server; you are running a server that will never be fixed again. For anything holding personal data, that is difficult to defend under KVKK's requirement for appropriate technical measures, and it will be raised in any serious security assessment or insurance review.

Plan to be off the platform before that date, not to start planning on it.

The other trigger: hardware warranty

Aligning the operating system upgrade with a hardware refresh is usually the cheapest path, because you are going to have downtime either way. Doing them separately means two migration projects and two outage windows.

If the hardware warranty expires within a year of the OS support date, treat them as one project.

In-place upgrade or migrate?

In-place upgrading is faster and preserves configuration. It also carries forward every accumulated misconfiguration, orphaned service account, and setting nobody remembers making. And if it fails partway, you are recovering a broken server rather than switching back to a working one.

For anything important we migrate instead: build the new server alongside, move roles and data deliberately, verify, then decommission. It takes longer, and the rollback is simply leaving the old server switched on.

In-place upgrades are reasonable for non-critical single-purpose machines where rebuilding costs more than the risk.

Order of operations

• Inventory first. What roles does this server hold? Domain controller, file server, print, DHCP, DNS, certificate authority, line-of-business application? Servers accumulate roles nobody documented.
• Check application compatibility. Older line-of-business applications are the usual blocker. Get vendor confirmation in writing before scheduling anything.
• Take a full backup and verify it restores. Not just take it — verify it.
• Build alongside and test with real users. A pilot group finds things a checklist does not.
• Migrate roles one at a time, with a verification step after each.
• Keep the old server available but offline for a few weeks. The thing you forgot always appears in week two.

Domain controllers deserve particular care: promote the new one, let replication settle and verify it, transfer the FSMO roles deliberately, then demote the old one properly rather than switching it off.

What to fix while you are there

A migration is the one moment when changing structure is cheap, because you are rebuilding anyway.

Take the opportunity to correct the file share permission structure that grew organically over eight years, remove the service accounts belonging to people who left, review group policy that nobody has read since it was written, and document what the new server actually does.

Skip this and you will carry the same problems into the next platform, and have the same conversation in five years.