Windows Server upgrade paths, and when in-place is the wrong instinct

An in-place upgrade preserves roles, features, settings, data and installed applications. It is supported, it is well-tested, and it is considerably faster than building a replacement.

It also preserves the registry changes made during a 2014 incident, the service account someone configured by hand, the scheduled task nobody can explain, and the third-party agent that is two major versions behind. That is the real trade, and it is not a technical one.

Requirements: what to establish before choosing

The supported path. Windows Server supports in-place upgrade across a limited number of versions — broadly, one or two releases forward, not arbitrary jumps. An older server may need two sequential upgrades to reach a current version, which changes the economics considerably against a rebuild. Check the supported path for your exact source and target editions before anything else.

The edition and the activation. Standard to Standard, Datacenter to Datacenter. Standard can go to Datacenter; the reverse is not an upgrade. Licensing is decided here, not later.

The workload’s own support position. The application running on the server has its own supported operating system matrix, and it is frequently narrower than Windows Server’s own. Upgrading the operating system under an application the vendor does not support on that version leaves you unsupported for the thing that matters.

The current support dates. Windows Server 2016 and 2019 are in or approaching the later parts of their lifecycle, and running past end of support means no security updates. Confirm the current dates rather than working from memory — this is the constraint that usually sets the deadline.

A tested restore. Not a backup — a restore you have actually performed, for the reasons in designing Azure backup and recovery around a tested restore. An in-place upgrade that fails part-way leaves a server in a state where the recovery path is the backup, and finding out then that the backup does not restore is a bad afternoon.

Design: the decision

In-place upgrade is the right choice when:

• The server has a well-understood configuration you actively want to keep.
• The workload is difficult or risky to reinstall — a legacy application with no current installer, or one whose configuration is not reproducible.
• The supported path is a single hop.
• Downtime for the upgrade duration is acceptable, and a rollback window exists.
• The hardware or virtual machine is staying.

Rebuild is the right choice when:

• The configuration has accumulated over years and nobody can fully account for it. This is the most common case and it is usually decisive.
• You are crossing more than one version, so in-place means sequential upgrades.
• The server has been compromised, or you suspect it has. An in-place upgrade preserves whatever is there.
• The workload can be installed cleanly and its data migrated.
• You want to change something fundamental — edition, Server Core versus Desktop Experience, disk layout, domain membership.
• You have the capacity to run old and new in parallel, which gives you a rollback that in-place cannot.

Neither is right when the server should not exist. An upgrade is a good moment to ask whether the role still needs a dedicated server, whether the workload belongs in Azure, or whether three servers should be one.

The instinct toward in-place is usually about time. The instinct is worth resisting for the specific reason that a rebuild gives you a parallel-run rollback and an in-place upgrade does not.

Deployment: in-place, done properly

1. Inventory the server first. Roles and features, installed software with versions, local accounts and groups, scheduled tasks, services and their accounts, certificates, firewall rules, registry customisations, share permissions, and the drivers and agents in place. This document is what you will need if anything goes wrong, and it is also what tells you whether a rebuild is actually easier.
2. Check compatibility of every third-party agent — backup, antivirus, monitoring, management — against the target version. These are the most common cause of a post-upgrade problem, and the fix is usually to update them before the upgrade rather than after.
3. Take a full backup, and confirm the restore. For a virtual machine, a checkpoint gives you a fast rollback — but take the backup regardless, because a checkpoint is not a backup and a long-running checkpoint has its own consequences.
4. Remove what you do not need. Uninstall obsolete software and roles before upgrading rather than carrying them forward. This is the one chance to reduce the inherited surface.
5. Run the upgrade from the mounted media with the setup options for keeping files and applications. Follow the current documented procedure rather than a remembered one.
6. Do not interrupt it. An interrupted in-place upgrade is the scenario the rollback plan exists for.
7. Patch immediately afterwards, before returning the server to service.

For a domain controller specifically, the reasonable default is different: add a new domain controller on the current version, let it replicate, move roles, and demote the old one. A domain controller is a replica, which makes replacement straightforward and upgrade unnecessary. The same logic appears in Active Directory forest recovery planning.

For a cluster node, use the documented rolling upgrade process rather than upgrading nodes ad hoc — and drain each node properly, confirming health between nodes as in Storage Spaces Direct: what actually breaks.

Validation

Validate against the inventory you took, not against a general impression:

• Every role and feature present and running.
• Every service running, under the account it was configured with. Service account changes after an upgrade are a known category of problem.
• Scheduled tasks present and enabled — check the ones that run monthly, which will not have fired yet.
• Certificates present and bound to the right services.
• Firewall rules intact, particularly custom ones.
• Share and NTFS permissions unchanged.
• Third-party agents running, checking in to their management systems and actually protecting the server. A backup agent that is installed but not backing up is a common post-upgrade state.
• The workload itself validated by someone who uses it, not only by you.
• The server visible and healthy in monitoring.

Then leave it a full business cycle before decommissioning any rollback path. Monthly processes surface late.

Rollback

In-place upgrade has a limited rollback window. Windows retains the previous installation for a period after an upgrade, allowing a return to the prior version, and that retention is time-limited and space-consuming. Know the window, and do not treat it as a general safety net — it will not be available weeks later when a monthly process fails.

Virtual machine checkpoints are the practical rollback for the upgrade itself, taken immediately before and removed once validation completes. Do not leave them in place; a long-lived checkpoint carries its own performance and storage problems.

A rebuild’s rollback is the old server, still running, until you decide otherwise. That is a materially better position, and it is the strongest argument for rebuilding when the choice is close.

Operations

Do this on a schedule, not at end of support. Organisations that upgrade continuously spend less effort than those that face an estate-wide migration every several years, and they carry less risk.

Keep the inventory. The document produced in step one is useful long after the upgrade, and it is the thing that makes the next decision easier.

Record what you removed. Someone will ask about the feature you uninstalled in step four.

Verification and limits

The existence and constraints of supported in-place upgrade paths, edition upgrade rules, the time-limited previous-installation rollback and the preference for replacing rather than upgrading domain controllers were checked against current Microsoft documentation on 20 September 2026. The decision framework and the validation checklist are my own practice.

No upgrade was performed for this article. In-place upgrade is a one-way operation outside its limited rollback window: confirm the supported path for your exact versions, verify a restore rather than a backup, check third-party agent compatibility first, and confirm current lifecycle dates against Microsoft’s lifecycle documentation rather than this article.

References

• Upgrade and conversion options for Windows Server
• Perform an in-place upgrade of Windows Server
• Windows Server release information
• Cluster operating system rolling upgrade