Evincia
SQL Server 2016 end of support: what actually changed, and what to do about it
The extended-support end date for SQL Server 2016 was July 14, 2026, and if you own or inherited a system still running on it, this page lays out what changed and what to do next.
What ended on July 14, 2026
The extended-support end date for SQL Server 2016 was July 14, 2026. On that date, Microsoft stopped shipping security updates for it under the standard lifecycle. The software itself does not change. It keeps running, and a query that ran on July 13 runs the same way on July 15.
Extended support was already narrow. Mainstream support for SQL Server 2016 ended on July 13, 2021, and since then the product has received security fixes only, no functional, performance, or scalability updates. July 14, 2026 took away the last of it.
One detail catches teams that assume they are covered: the servicing baseline is Service Pack 3. SP3 is the only service pack whose support reached the end-of-support date; SP2 and SP1 left support years earlier (in 2022 and 2019). An instance sitting on an older service pack is already unsupported today, regardless of the July 2026 date.
After July 14, 2026, you can no longer tell an auditor or a cyber-insurer that the database under your application still receives security patches. Those are the people who now ask.
Extended Security Updates are now a paid subscription
Extended Security Updates (ESU) are Microsoft's paid program for patching a product after its support ends. With SQL Server 2012, there was a way to get them for free: move the workload onto an Azure virtual machine and the updates were included. That changed with SQL Server 2016. Its ESUs are a paid subscription wherever the database runs, Azure VMs included.
What the program covers, from Microsoft's SQL Server ESU documentation:
- It covers the Enterprise and Standard editions. Express, Web, and Developer editions do not get a paid subscription of their own -- though a Developer instance sitting alongside covered production receives the updates at no charge.
- There are two ways to qualify: active Software Assurance under an EA, EAS, SCE, or EES agreement, or pay-as-you-go billing through Azure with no Software Assurance at all. Either way, enrollment runs through Azure Arc -- even a server that never leaves your data center connects to Arc to subscribe -- and an instance that cannot reach Arc must be bought through volume licensing and registered as disconnected.
- It is available for up to three years past end of support -- for SQL Server 2016, through July 17, 2029.
- It delivers Critical-severity security fixes only, as rated by Microsoft's Security Response Center. There is no release schedule -- an update ships only when such a vulnerability is found, so there is no patch window to plan around -- and it includes no functional fixes, no bug fixes, and no product support.
ESU keeps the Critical patches coming, but it is a recurring fee with a three-year limit. Microsoft prices it at roughly 75% of the on-premises license cost each year, so three years of updates cost more than the license did, and at the end you are on the same version you started with. Enrolling late does not defer the cost either: subscribe in January 2027 and the first bill back-charges you to July 14, 2026, the start of the ESU year. Use it to buy time for a migration already underway, not as a way to stay on 2016. The terms above come from Microsoft's SQL Server Extended Security Updates documentation ↗
The realistic options
There are five options for a SQL Server 2016 instance. Most estates end up using more than one.
- Subscribe to ESUs. Keeps the Critical patches coming, but it is a recurring cost with a three-year limit, and at the end you are on the same version you started with.
- Upgrade in place to a current SQL Server. A direct upgrade from SQL Server 2016 SP3 to 2019, 2022, or 2025 is supported; 2025 has been generally available since November 2025 and buys the most runway, with support into 2036, where 2019 is already past its own mainstream support. It is the least disruptive path architecturally, but the compatibility work is real: raising the database compatibility level can change query plans, and the deprecated T-SQL, the SQL Agent jobs, and the linked servers all have to be checked. The part that gets forgotten is the .NET application on top, pinned to old data providers, drivers, and Framework versions that assume the old server.
- Re-platform to Azure SQL. Which target is actually open to you (SQL Managed Instance, SQL Database, or SQL Server on an Azure VM) depends on what the database contains, not on preference. Cross-database queries, SQL Agent, CLR assemblies, and linked servers each rule out one or more of them.
- Consolidate or decommission. Sometimes the instance should not survive at all: it backs a retired application, or its data belongs somewhere you already run. Worth confirming before it gets migrated out of habit.
- Do nothing. Some teams land here, and it is better to choose it on purpose than back into it. Doing nothing still has a cost; it just shows up later, at the next renewal, audit, or diligence review.
What decides which option you have
All five options are decided by the same thing, and it is not on the inventory spreadsheet: what the database and the application code contain.
How hard a system is to move lives in the details: stored procedures the application depends on, SQL Agent jobs nobody owns anymore, linked servers into other databases, cross-database queries that couple two systems together. On the application side, it is a .NET tier pinned to old data providers, connection stacks, and Framework versions written against this exact server.
Until someone reads that layer, a migration estimate is a guess. Two instances on identical SQL Server builds can be a weekend of work or a two-quarter program, and the version number looks the same either way. The SQL Server modernization risk breakdown and the legacy .NET triage checklist are where that reading starts.
Where Evincia fits
This is the reading Modernization Shield is built to produce. A deterministic, Roslyn-based engine reads the .NET codebase and surfaces the signals that couple it to SQL Server -- the connection stacks, the embedded SQL, and the data-access patterns that decide how hard the database is to move -- and a senior architect reviews the database-side evidence and renders the judgment the engine does not. The engine analyzes .NET code; it does not automatically analyze SQL or T-SQL, so SQL Server risk surfaces through those code-side signals plus that architect review, never a claim to scan the database itself. It arrives as one fixed-scope deliverable, the Legacy Modernization Risk Report, in 7 to 10 business days at a fixed fee -- see how Evincia works for the full sequence.
The dates around this one
SQL Server 2016 rarely sits alone. It usually runs under a .NET application on a Windows Server of the same generation, next to newer SQL Server instances that are closer behind than they look. The end-of-support dates cluster:
| Platform | Extended support end date |
|---|---|
| Windows Server 2016 | January 12, 2027 |
| SQL Server 2017 | October 12, 2027 |
| SQL Server 2019 | January 8, 2030 (mainstream support ended February 28, 2025) |
| SQL Server 2022 | January 11, 2033 |
Not all of these are urgent. But in most estates 2016 is the first of the group to reach end of support, not the last, and moving it on its own tends to strand the systems around it. The full, maintained calendar lives on the Microsoft end-of-support reference.
What to do this quarter
None of this needs a formal program. A quarter spent taking inventory is enough to base the decisions on what is actually there.
- Inventory every SQL Server 2016 instance, including the Express sprawl -- the free installs that ride along with a vendor app or a developer's machine and never make it onto the official list.
- Confirm the service pack on each one. Anything below SP3 is already unsupported, and that changes the urgency.
- If an instance is heading for ESUs rather than an upgrade, install and validate the latest cumulative update before you subscribe. ESUs are built on the most recent CU, and an instance that skipped them can fail to take the first update cleanly.
- Map what is coupled to each instance: the applications that connect to it, the SQL Agent jobs, the linked servers, and the reports that read from it. This is where the cost of moving hides.
- Decide per instance, not per estate. One database may warrant an in-place upgrade, the next a re-platform, the third a decommission. A single blanket decision is almost always wrong for some of them.
- Get the evidence before the budget conversation begins. A cost estimate built on reading the systems holds up when someone pushes on it.
Did SQL Server 2016 stop working on July 14, 2026?
No. The software keeps running exactly as before; it does not deactivate or degrade. What stopped was Microsoft shipping security updates under the standard lifecycle. The real exposure is that any vulnerability found after that date stays unpatched, unless you are enrolled in Extended Security Updates.
Are Extended Security Updates free if I move to Azure?
Not for SQL Server 2016. That was true for SQL Server 2012, which is where the assumption comes from. Starting with SQL Server 2016, ESUs are a paid subscription in every environment, including Azure virtual machines. Enrollment runs through Azure Arc on a pay-as-you-go basis.
How long can ESUs carry SQL Server 2016?
Up to three years past the end-of-support date, through July 17, 2029 for SQL Server 2016. They cover Critical-severity security fixes only, on the Enterprise and Standard editions. After that there is no further extension.
Does upgrading SQL Server force changes in the .NET application?
Often, yes. The application tier is usually pinned to specific data providers, drivers, and .NET Framework versions written against the old server, and a raised compatibility level can change query behavior underneath it. That is why the database version and the application it serves are best assessed together, not one at a time.