October 27, 2026
Plenty of business applications still run on a Windows Server 2016 box with SQL Server 2016 installed on the same machine. It was a sensible build at the time. Today it puts two separate support deadlines on one server, and the order you handle them in decides whether the upgrade actually leaves you supported.
Windows Server 2016 end of support arrives on January 12, 2027. SQL Server 2016 already passed its date. Its extended support ended July 14, 2026, so any production database still on 2016 has been running unsupported for months.
Why the Database Is the More Urgent Problem
Most attention goes to the operating system because its date is still ahead. The database deserves it more. It holds the data that matters, and it has already stopped receiving security fixes.
The two products also block each other. SQL Server 2016 is not supported on Windows Server 2022 or Windows Server 2025. If a team upgrades the operating system in place and leaves the database alone, they finish the project on a supported OS running an unsupported database that Microsoft no longer certifies for that OS. That is arguably worse than where they started.
So the planning question is not "how do we upgrade Windows?" It is "where should this workload live, and on what versions, when we are done?"
Your Four Realistic Options
Every server in scope lands in one of these paths. Most estates end up using more than one.
1. Upgrade both, side by side
Build a new server on a current Windows Server release with a current SQL Server version, migrate the databases and application, test, and cut over. This is the cleanest outcome and the one we recommend for most business-critical systems. It also avoids carrying ten years of configuration drift onto the new machine.
2. Move the workload to Azure
Lifting the server into Azure, or moving the database to a managed service such as Azure SQL, takes patching for the platform off your team's plate entirely. It works best when the application is already reasonably modern. Older apps with hard-coded server names, local file dependencies, or Windows authentication quirks need cleanup first. Our server engineering team handles that assessment as part of planning a move.
3. Buy time with Extended Security Updates
Microsoft offers Extended Security Updates for Windows Server 2016 through Azure Arc, with updates delivered through the Azure portal for both on-premises and multi-cloud servers. SQL Server 2016 has its own, separate Extended Security Updates program with different enrollment and billing.
ESUs are a bridge, not a destination. They make sense when an application cannot move before the deadline because of a vendor dependency, a frozen period, or a larger replatforming already underway. They make less sense as a way to avoid a decision, because the cost recurs and the upgrade is still waiting at the end.
4. Retire the application
Every inventory turns up a few servers running something nobody uses anymore, or something a newer system already replaced. Decommissioning is the cheapest upgrade available. Confirm the data retention requirements, archive what you need, and turn it off.
Questions to Answer for Every Server
Before choosing a path, gather the same facts for each machine:
- What runs on it? The application, any scheduled tasks, any services, and anything else that quietly ended up there over the years.
- Which SQL Server version and edition? Including any databases that were added after the server was first built.
- What depends on it? Other applications, reports, integrations, and file shares that point at this server by name.
- Who owns the application? And whether that person still works here.
- What is the hardware age? A server bought in 2016 is near the end of its useful life regardless of the software on it.
- Is the application itself supported? A commercial package may require a vendor upgrade before it can run on newer Windows or SQL versions.
The dependency question is the one that causes surprise outages. A report server, an ERP integration, or a nightly export job that points at the old machine by hostname will fail silently after cutover. Finding those connections before migration day is most of the work.
Upgrading SQL Server Without Breaking the Application
Moving a database to a newer SQL Server version is usually straightforward. The part that needs care is what happens to performance afterward.
Newer versions change how the query optimizer behaves. Most queries run the same or faster. A few run slower, and those few are often the ones the business notices first. Keeping the database compatibility level at the old setting during cutover, then raising it deliberately after testing, gives you a controlled way to adopt the newer behavior.
Older applications are also the most likely to carry slow queries, missing indexes, and schema decisions that made sense at a smaller scale. A version upgrade is a good point to address them, which is the same work we cover in tuning legacy database performance during modernization.
Check the Application Layer Too
Servers that have been in place since 2016 often host applications from the same era. Before moving them, confirm the application framework is still supported. Custom apps built on early .NET Core versions are long past support, and apps on .NET 8 lose support on November 10, 2026, which means a server migration and an application framework upgrade can often be planned together.
Combining them is not always the right call. Changing the server, the database version, and the application runtime in a single cutover makes problems harder to isolate. For critical systems, we usually sequence them: infrastructure first, then the application, with a stable checkpoint in between.
What a Realistic Timeline Looks Like
With the Windows Server deadline less than three months away, a practical sequence looks like this:
| Phase | Focus |
|---|---|
| Weeks 1 to 2 | Inventory every 2016 server, its SQL version, dependencies, and owner |
| Weeks 2 to 3 | Assign each server a path: side-by-side upgrade, Azure, ESU, or retire |
| Weeks 3 to 10 | Migrate the highest-risk systems first, starting with internet-facing and data-heavy workloads |
| Before January 12 | Enroll anything that will not make the date in ESU, with a documented move date |
The order of the last two steps matters. Deciding on ESUs early, for the systems that clearly cannot move in time, removes pressure from the migrations that can.
Planning the Move With Us
We plan and run these migrations for organizations that cannot afford downtime on the systems involved: ERP-connected databases, customer portals, and internal applications that operations depend on daily. Our approach starts with the inventory and dependency map, because that is where the risk of a failed cutover actually lives.
If you have Windows Server 2016 or SQL Server 2016 in production and are not sure which path fits each system, talk with our team. We can help you sort the estate, decide what moves when, and keep the business running while it happens.