SQL Server 2016 End of Support: What Changes Now

What actually happened on July 14, 2026

SQL Server 2016 reached the end of its extended support window on July 14, 2026. Mainstream support had already ended on July 13, 2021. Both dates come straight from Microsoft's lifecycle documentation.

Here is what did not happen: nothing stopped working. Your database did not shut down, refuse connections, or start throwing errors. Every query that ran on July 13 ran identically on July 15. This is the single most important thing to understand about end-of-support dates, and the reason they get quietly ignored for years.

What did happen is that Microsoft stopped shipping security patches for newly discovered vulnerabilities. Not performance fixes, not bug fixes — those stopped in 2021 when mainstream support ended. As of July 15, 2026, when a new vulnerability is found in the SQL Server 2016 engine, no public fix is coming unless you are paying separately for Extended Security Updates.

The practical risk is not that your database breaks. It is that a vulnerability gets published, the details become widely known, and your unpatched instance stays vulnerable indefinitely. For a database sitting behind a public-facing IIS website, that exposure compounds over time rather than staying flat.

What Extended Security Updates actually buy you

Extended Security Updates are Microsoft's paid extension for customers who cannot migrate before the deadline. For SQL Server 2016, the ESU program runs in three annual windows, per Microsoft's published lifecycle data:

Three things about ESU are worth being clear on before treating it as a plan.

It covers security fixes only. Critical and important security updates, as Microsoft classifies them. No new features, no performance improvements, no ordinary bug fixes, and no general technical support unless you hold a separate support agreement.

The price escalates. ESU is priced annually and increases each year, by design — it is structured to be more expensive than migrating, because it exists to buy planning time rather than to be a permanent arrangement.

It is free if the workload runs in Azure. This is the detail most owners miss. Move the same SQL Server 2016 instance onto an Azure virtual machine and Extended Security Updates are included at no additional charge. That single fact reshapes the economics for a lot of small businesses, and it is covered in more depth in the article on what Extended Security Updates actually buy.

Where a SQL Server 2016 database can go

There are four realistic destinations, and the right one depends far more on how the application talks to the database than on the database itself.

Azure SQL Managed Instance. The closest managed equivalent to a real SQL Server instance. It supports SQL Agent jobs, cross-database queries, CLR, and most of the instance-level features that break when people try to move to a single managed database. For a legacy application that was written against a full SQL Server instance and makes assumptions accordingly, this is usually the least painful managed target.

Azure SQL Database. A single managed database rather than a full instance. Cheaper and simpler to operate, but it drops instance-scoped features — SQL Agent chief among them. If your application relies on scheduled jobs living inside the database, those need somewhere else to run. Worth checking before committing.

SQL Server on an Azure virtual machine. The same SQL Server you have now, on infrastructure you no longer own. You still patch it, back it up, and manage it — but the hardware risk is gone and ESU is included. This is the pragmatic path when the application is too fragile to risk a platform change at the same time as an infrastructure change.

A newer SQL Server on-premises. Occasionally the right answer, particularly where data residency or latency requirements genuinely rule out cloud hosting. It resets the support clock without changing the operating model, though it does mean buying hardware and repeating this exercise in a few years.

What this means if the database sits behind a website

Most of the SQL Server 2016 instances still running in small businesses are not standalone — they are the back end of a web application on IIS. That changes the shape of the problem in two ways.

First, the exposure is larger. A database on an isolated internal network with no route to the internet is a contained risk. A database reachable, however indirectly, through a public web application is not. Unpatched database vulnerabilities matter considerably more when there is a path to them from outside.

Second, the database is rarely the only thing that is old. A SQL Server 2016 instance is very often paired with a Windows Server that is also past or approaching its own end-of-support date, running an IIS site built against a framework version nobody has touched in years. Migrating the database alone leaves a modernized data tier talking back to an aging application server, which reintroduces most of the risk the migration was meant to remove.

This is why the database deadline is usually worth treating as the trigger for a broader look rather than as an isolated task. The rehost, rebuild, or replace decision applies to the application in front of it, and the two decisions are easier to make together than sequentially.

Frequently asked questions