Server OS Upgrade Guide: How to Upgrade Windows Server and Ubuntu Without Breaking Production

A server OS upgrade rarely lands on the roadmap because it is exciting. It lands there because the clock is running. Windows Server 2016 is heading toward the end of Microsoft’s extended support in January 2027, and Ubuntu 20.04 LTS has already moved past standard security maintenance in the Ubuntu release cycle. If your websites, applications and scheduled jobs still run on those platforms, the question is no longer whether to plan an OS upgrade. It is how to carry out the server OS upgrade without breaking anything the business depends on.

This guide explains what a server OS upgrade involves, how to choose between an in-place upgrade and a migration, which risks to control, and a step-by-step OS upgrade process that works for both Windows Server and Ubuntu. It draws on a real Intellinez project that moved Windows Server 2016 to 2019 and Ubuntu 20.04 to 22.04 across DEV, QA, UAT and PROD, which you can read in full in our Windows and Linux OS upgrade case study.

What Is a Server OS Upgrade?

Quick Answer: A server OS upgrade moves a server from one operating system version to a newer, supported one, such as Windows Server 2016 to Windows Server 2019 or Ubuntu 20.04 LTS to Ubuntu 22.04 LTS. A safe server OS upgrade covers more than the operating system itself. It includes the applications, hosting configuration, scheduled jobs, certificates and traffic routing that run on top of it.

It helps to separate a server OS upgrade from two things it is often confused with. Patching keeps the current operating system version secure, but it does not change the version, so the support end date stays where it is. A migration moves workloads to a different server, which may or may not run a newer operating system. An OS upgrade changes the operating system version itself, and everything that depends on that version has to be checked afterwards.

That last part is where most of the effort goes. The operating system change in an OS upgrade is often the shortest step. Proving that every website, application pool, service and scheduled task still works is what makes a server OS upgrade successful.

Why a Server OS Upgrade Can’t Wait

Security and Support Lifecycle

Support dates are the clearest reason to schedule an OS upgrade. Microsoft lists extended support for Windows Server 2016 as ending in January 2027, while Windows Server 2019 stays in extended support until January 2029. On the Linux side, Ubuntu 20.04 LTS reached the end of standard security maintenance in May 2025, while Ubuntu 22.04 LTS is covered until May 2027, according to the Ubuntu release cycle.

Ubuntu Pro can extend security maintenance for 20.04 to May 2030, which buys time. It does not remove the need for a server OS upgrade. It moves the deadline, and the work becomes harder the longer it is postponed.

Compatibility With Modern Software

Newer applications, libraries, runtimes and security tools are built and tested against current operating systems first. Staying on an older release means a growing list of packages you cannot install, versions you cannot move to and vendor support requests that start with “please upgrade your OS”. An OS upgrade removes that ceiling and makes later application upgrades easier. Postponing the server OS upgrade only makes that ceiling harder to lift.

Operational Consistency

A mixed estate of old and new operating systems is harder to document, monitor and support. Every older server carries its own exceptions, such as legacy configurations, one-off workarounds and undocumented dependencies. Standardizing through a planned server OS upgrade gives administrators one baseline to manage, which simplifies patching, hardening and troubleshooting.

In-Place Upgrade vs. Migration: Which Server OS Upgrade Approach Fits?

There are two ways to carry out a server OS upgrade. Microsoft’s upgrade and migration guidance describes an in-place upgrade as installing a newer version of Windows Server over the existing one while keeping settings, server roles, features and data. A migration, in Microsoft’s words, moves roles or features from a source server to a different destination server. Ubuntu’s upgrade path is in-place by design, using the do-release-upgrade tool described in the Ubuntu Server upgrade documentation.

Here is how the two approaches compare in plain terms:

Choose an in-place OS upgrade when the server has a simple role, a well-understood configuration and a tested backup. Choose a migration when the server has accumulated years of undocumented changes, when you want a clean baseline, or when you need the old server intact as a rollback option. Many estates use both, depending on the environment and the criticality of the workload.

Two compatibility checks apply whichever route you take. For Windows, Microsoft notes that not all roles support in-place upgrade, so check the role and feature matrix before committing. The supported upgrade paths table confirms that Windows Server 2016 to Windows Server 2019 is a supported path. For Ubuntu, direct upgrades run between sequential LTS releases, so 20.04 goes to 22.04, and skipping releases requires staged upgrades.

The Main Risks of a Server OS Upgrade and How to Control Them

A server OS upgrade fails in predictable ways. Each risk below has a matching control, and planning for them in advance is what separates a controlled OS upgrade from an emergency.

Application and OS Incompatibility

An application that ran fine on the old operating system may depend on a runtime, library or Windows feature that behaves differently on the new one. The control is a pre-upgrade assessment of every application and dependency, followed by testing in a non-production environment before the OS upgrade touches production.

Lost Configuration, Bindings and Certificates

Domain bindings, SSL/TLS certificates, application pool settings, web.config values and file permissions are easy to lose or misconfigure, particularly in a migration-style OS upgrade. The control is to document and back up configuration before you start, then validate each item afterwards, rather than assuming it carried over.

Service and Scheduled Job Failures

Windows services, systemd services, cron jobs and scheduled tasks can quietly stop working after an OS upgrade, and nobody notices until a report fails to run. The control is to inventory every scheduled workload first and validate each job independently after the upgrade.

Downtime and Rollback

Any server OS upgrade needs a window in which the server may be unavailable, and a way back if something goes wrong. The control is a controlled maintenance window, a tested backup and a written rollback plan agreed before anyone starts.

Security Configuration Drift

Firewall rules, monitoring agents and security tooling can change or need reinstalling after an OS upgrade. The control is a post-upgrade security validation that confirms your baseline is still in place.

A Step-by-Step Server OS Upgrade Process

The following process mirrors how we approach a server OS upgrade at Intellinez. It works for Windows Server, Ubuntu or a mixed estate, and it keeps DEV, QA, UAT and PROD separate so that each environment is proven before the next one is touched.

Step 1: Assess the Environment Before the Server OS Upgrade

Start with an inventory. For every server, record the operating system version, the websites and applications it hosts, application dependencies and runtime requirements, IIS configuration and application pools, domains, bindings and certificates, firewall and network settings, scheduled tasks, monitoring and security agents, database connectivity, file and folder permissions, and backup and recovery requirements. This inventory is the foundation of the whole OS upgrade plan.

Step 2: Back Up and Plan the Rollback

Both Microsoft and Ubuntu stress backups before an upgrade. Microsoft advises always backing up your system and important files before performing an in-place upgrade, clean install or migration. Ubuntu’s documentation notes that although upgrades are normally safe, something can always go wrong. Back up data and configuration, agree a maintenance window, and write down exactly how you would roll back.

Step 3: Upgrade a Non-Production Environment First

Run the first OS upgrade in DEV, then QA and UAT, and only then production. Each environment should have its own servers, domains and configuration so that nothing from one environment leaks into another. Problems found in DEV cost an afternoon. Problems found in production cost much more.

Step 4: Windows Server 2016 to 2019, Upgrade and Validate

After the Windows Server OS upgrade, validate server roles and features, IIS, application pools, Windows services and scheduled tasks. Then check network, firewall, file permission, monitoring and security settings, and confirm applications can still reach their databases and dependencies.

Step 5: Ubuntu 20.04 to 22.04, Upgrade and Validate

For Ubuntu, the recommended tool is do-release-upgrade. Before running it, complete apt update and apt dist-upgrade, check there is enough disk space and read the release notes. Ubuntu’s documentation notes that third-party repositories and PPAs are disabled during the release upgrade, so plan to re-enable them afterwards, and that a reboot is required to complete the upgrade. After the Linux OS upgrade, validate SSH access, network configuration, installed packages, web and application services, systemd services, cron jobs, file permissions, SSL certificates and monitoring agents.

Step 6: Migrate Websites, Hosting Configuration and Domains

Once the operating system is upgraded, move or re-verify the workloads. On Windows, that means IIS websites, application pools, domain and HTTPS bindings, SSL/TLS certificates, physical path mappings, permissions and web.config settings. On Linux, it means the web and application stack and any WordPress or PHP applications. Use environment-specific domains so DEV, QA, UAT and PROD stay strictly separate throughout the OS upgrade.

Step 7: Move Scheduled Jobs and Configure Load Balancing

Migrate automated jobs deliberately and, where it makes sense, onto dedicated job servers so background processing does not compete with your web workloads. Where an application runs on more than one server, configure a load balancer to distribute traffic and reduce dependence on any single server. A well-planned server OS upgrade is a good moment to improve availability, not only to change versions.

Step 8: Validate, Then Promote to Production

Run the full validation described in the next section in every environment. Perform a final production validation to confirm that live applications are accessible and working correctly after the OS upgrade, and keep the rollback plan ready until you are confident.

How to Validate a Server OS Upgrade

Finishing the OS upgrade is not the end of the work. We validate at four levels, and each level catches a different kind of problem:

Treat validation as a checklist with named owners rather than a quick look at the home page. A site that loads can still have a failed scheduled job or an expired binding that only shows up days after the server OS upgrade.

Server OS Upgrade Best Practices Checklist

• Inventory every server, application, job, certificate and dependency before the OS upgrade begins.
• Check vendor support dates so the target of your OS upgrade stays supported for years, not months.
• Test role, feature and application compatibility before committing to an in-place OS upgrade.
• Take backups and verify that you can actually restore from them before any server OS upgrade.
• Upgrade DEV first, then QA and UAT, and keep PROD strictly separate.
• Schedule a maintenance window and write a rollback plan before starting.
• Re-enable third-party repositories and review package sources after an Ubuntu release upgrade.
• Re-validate bindings, certificates, permissions and scheduled jobs after every server OS upgrade.
• Separate background jobs from web workloads where it helps reliability.
• Document what changed so the next OS upgrade starts from a known baseline.

A Real Server OS Upgrade: What Intellinez Did

In our own Windows and Linux OS upgrade project, we upgraded Windows Server 2016 to Windows Server 2019 and Ubuntu 20.04 LTS to Ubuntu 22.04 LTS, then migrated the websites, applications and automated jobs running on them across Development, QA, UAT and Production.

On the Windows side, 20 websites went to a dedicated Development application server, 10 sites to each of two QA/UAT application servers and 5 sites to each of two Production application servers. Load balancers were configured for QA/UAT and Production, and automated jobs were moved onto dedicated job servers for Development and Production, with QA and UAT jobs configured separately. On the Linux side, 20 WordPress websites were migrated to the Development server and 20 to the Production server, with WordPress and CodeIgniter applications hosted two per environment.

Each server OS upgrade in that project followed the same sequence, and the lesson from it is that the OS upgrade itself was only one stage of nine. The assessment before it and the validation after it carried the real weight. If this resonates, our SDDC infrastructure migration and CI/CD deployment automation case studies show the same discipline applied to other infrastructure work, and our post on replatforming in cloud migration covers the related question of moving workloads to the cloud.

How Intellinez Can Support Your Server OS Upgrade

Most teams can run an OS upgrade on a single server. The harder part is doing it across several environments, with dozens of sites, scheduled jobs and load-balanced servers, while the business keeps running. That is where an experienced team and a repeatable process matter. We have run this process ourselves, and we can help you plan and carry out your server OS upgrade. We also support the web applications and marketing websites that run on the upgraded infrastructure. If you are weighing your options, you can also read how our team thinks about modern software development.

Key Takeaways

• A server OS upgrade is an infrastructure project, not just a version change. Applications, hosting configuration, jobs and traffic routing all depend on it.
• Support dates drive the schedule: Windows Server 2016 extended support ends in January 2027, and Ubuntu 20.04 LTS has left standard security maintenance.
• Choose between an in-place OS upgrade and a migration based on how complex and well-documented each server is.
• For every server OS upgrade, assess first, back up, upgrade non-production before production, and validate at server, application, hosting and load balancer level.
• Keep DEV, QA, UAT and PROD separate so each environment is proven before the next one is touched.

Conclusion

Putting off a server OS upgrade does not make it disappear. It lets support dates, compatibility gaps and legacy configuration pile up until the upgrade becomes urgent and harder. A calm, staged OS upgrade, with assessment up front and validation at the end, gives you a more secure, stable and maintainable platform and a stronger base for whatever you build next. Whether you run a handful of servers or a multi-environment estate, the process is the same: understand what you have, protect it, upgrade in stages and prove it works. To see the process applied end to end, read our Windows and Linux OS upgrade case study.

Frequently Asked Questions

Ready to Plan Your Server OS Upgrade?

Whether you are upgrading one server or an entire multi-environment estate, a clear plan makes the difference. Tell us what you are running and we will help you plan a safe server OS upgrade.