SQL Server 2016 end of support (July 14, 2026): what to do now

What changed on July 14, 2026

On July 14, 2026, SQL Server 2016 reached the end of its extended support. Mainstream support had already ended in July 2021; since this summer, Microsoft no longer releases any fixes for this version, security fixes included. Only organizations that subscribe to Extended Security Updates (ESU) still receive critical fixes. Every edition is affected: Enterprise, Standard, Web, Express and Developer.

In practice, your instances keep running exactly as before. Nothing stops, no license expires, no warning message appears. That is precisely what makes this deadline so easy to put off, and it is why so many SQL Server 2016 servers are still in production today.

The real risks of running an unsupported version

• Security. Any vulnerability discovered after July 2026 stays open on your servers. And the SQL Server database often holds the most valuable data the company has: customers, invoices, payroll, production data.
• Compliance. Security questionnaires from large customers, cyber insurers, ISO 27001 audits, NIS 2 requirements: vulnerability management carries more and more weight in all of them, and “the version is no longer maintained by the vendor” is an answer that is getting harder and harder to defend.
• Vendor support. Microsoft no longer handles support cases for this version without ESU, and software vendors (ERP, payroll, line-of-business applications) are gradually dropping SQL Server 2016 from their compatibility matrices.
• The operating system. Many SQL Server 2016 instances run on Windows Server 2016, whose extended support ends in turn on January 12, 2027. Tackling both at once saves you from migrating twice.
• A step that keeps growing. The longer the migration is put off, the wider the gap in versions, drivers and skills you will have to close.

Step one: know exactly what you have

Before choosing an option, you need a reliable inventory. This read-only script returns the version, patch level and edition of each instance, then the compatibility level of each database:

/* Instance version, patch level and edition */
SELECT
    SERVERPROPERTY('ServerName')         AS instance,
    SERVERPROPERTY('ProductVersion')     AS version,     /* 13.0.x = SQL Server 2016 */
    SERVERPROPERTY('ProductLevel')       AS patch_level, /* SP3 expected */
    SERVERPROPERTY('ProductUpdateLevel') AS update_level,
    SERVERPROPERTY('Edition')            AS edition;

/* Databases, compatibility level and recovery model */
SELECT name, compatibility_level, recovery_model_desc, state_desc
FROM sys.databases
ORDER BY name;

A version starting with 13.0 is SQL Server 2016 (14.0 for 2017, 15.0 for 2019, 16.0 for 2022, 17.0 for 2025). Don't confuse the engine version with the database compatibility level: a database at level 130 hosted on SQL Server 2022 is fully supported. For support purposes, the engine version is what counts.

Also remember the instances that tend to be forgotten: Express editions installed by a line-of-business application, 2016 reporting (SSRS), integration (SSIS) or analysis (SSAS) servers, and test and development environments.

Option 1: buy time with ESU

Extended Security Updates keep critical-rated security fixes coming for up to three years, until July 2029. What you need to know before you sign:

• They only cover the Enterprise and Standard editions, and they contain only critical security fixes: no bug fixes, no new features.
• You buy them either through a volume licensing agreement with Software Assurance, or pay-as-you-go by connecting your servers to Azure Arc, billed hourly per core and cancelable at any time.
• The price goes up every year: according to the price lists circulated by Microsoft licensing specialists, roughly 75% of the license price in year one, then 150% and 300%. Have your reseller confirm these amounts, since they depend on your agreement.
• Unlike SQL Server 2014, ESUs for SQL Server 2016 are not free on Azure virtual machines.
• Signing up late doesn't save you anything: billing goes back to the start of the current ESU year, which is July 15, 2026 for the first year.

ESUs are a bridge, not a destination. The first year makes sense if it covers a migration planned within the next twelve months. Beyond that, the cumulative cost would more than pay for an upgrade.

Option 2: upgrade to SQL Server 2022 or 2025

This is the most common path. The two realistic targets today are SQL Server 2022 and SQL Server 2025: migrating to 2017 or 2019, both already out of mainstream support, would only push the problem down the road.

To choose between the two:

• Start with your vendors. If your ERP or line-of-business software is only certified on SQL Server 2022, the question is settled. If it is also certified on 2025, that version gives you the longest support window.
• Look at your edition. SQL Server 2025, released in November 2025, raises the Standard edition limits to 32 cores and 256 GB of memory, which can sometimes spare you the cost of Enterprise edition. Web edition, on the other hand, no longer exists in 2025.
• Use the move to right-size. SQL Server is licensed per core: a migration is the right time to check that your core count and edition match what you actually need.

Technically, an in-place upgrade from SQL Server 2016 SP3 is supported to both 2022 and 2025. Even so, we almost always recommend a side-by-side migration to a new server: it lets you test before the cutover, change the operating system at the same time, and keep the old server untouched as a fallback.

Option 3: move to Azure SQL

Azure SQL Managed Instance and Azure SQL Database take versions out of the equation: Microsoft updates the engine continuously, and backups and high availability are both included. That still doesn't make it an automatic choice. You need to check feature compatibility (cross-database queries, SQL Server Agent jobs, CLR, SSIS and SSRS services), the latency between your applications and the cloud, and above all compare the monthly cost with that of a server you are already depreciating.

What makes a migration succeed

1. A complete inventory: instances, databases, jobs, logins and passwords, linked servers, SSIS packages, SSRS reports, encryption certificates (TDE, encrypted backups).
2. Performance testing before the cutover. To limit surprises, keep compatibility level 130 on migration day, enable Query Store, then raise the level step by step while comparing execution plans.
3. A rehearsed cutover. Backup and restore, log shipping or an availability group, depending on how much downtime is acceptable: the real cutover should be the second or third, never the first.
4. A realistic rollback plan. A database restored on a newer version can never go back to SQL Server 2016. Your fallback is the old server, kept exactly as it was, with a clear decision about data entered after the cutover.
5. Post-migration follow-up: updating statistics, checking jobs and backups, and watching for regressions in Query Store during the first few weeks.

Where to start this week

• Run the inventory script above on every instance.
• List the affected applications and ask each vendor which versions they certify.
• Decide whether you need a first year of ESU to cover the migration period, or whether you migrate right away.
• Set a cutover date, even a tentative one: that date is what will move the project forward.

We handle this kind of project end to end, from inventory to cutover: see our SQL Server migration and upgrade service. If you don't yet know what state your instances are in, a SQL Server audit gives you a complete picture in a few days, end of support included.