SQL Server 2016 Is Now Unsupported — What to Do Now That July 14, 2026 Has Passed
Extended support for SQL Server 2016 ended July 14, 2026. If you're still running it, you're already unpatched and already carrying an audit finding. Here are your options today, what they cost, and the fastest safe path off.
SQL Server 2016 Is Now Unsupported — What to Do Now That July 14, 2026 Has Passed
Extended support for SQL Server 2016 ended on July 14, 2026. (Mainstream support ended back in July 2021 — 2026 was the end of the extended phase.) That date is behind us. If you are still running SQL Server 2016 in production today, you are running unpatched software, and every day adds exposure.
This is not a warning post anymore. It is a remediation post.
---
What Is Already True Today
Microsoft has stopped releasing security updates for SQL Server 2016. That means:
- Vulnerabilities are accumulating right now — new CVEs affecting the engine will not be patched on your instance
- You are already an audit finding — running unsupported software is a finding under PCI-DSS 6.3, HIPAA technical safeguards, and effectively every SOC 2 security category
- Microsoft Support will not help on a production incident — end-of-life means end of support engineering
- Cyber insurance gets complicated — many policies exclude claims on systems running unsupported software
We watched the same sequence with SQL Server 2012 (EOL October 2022) and 2014 (EOL July 2024). The organizations that got hurt were not the ones that migrated late — they were the ones that kept treating it as a future problem after the date passed.
Triage First: Know Your Exposure This Week
Before you pick a destination, get honest about where you stand:
1. Inventory every 2016 instance — including the forgotten reporting box and the vendor appliance nobody owns
2. Classify by data sensitivity and internet exposure — regulated or externally reachable instances go first
3. Confirm whether ESUs are in place — if not, you are unpatched, full stop
4. Document compensating controls — network isolation, restricted logins, monitoring. Auditors will ask what you did in the interim.
5. Set a decommission or upgrade date per instance — a dated plan is what turns a finding into a managed risk
Your Three Options
Free · 2 Minutes
How healthy is your database, really?
Get your database health score — spot risks before they become incidents.
Option 1: Upgrade to SQL Server 2019, 2022, or 2025
The most straightforward path, and the one most shops should take. SQL Server 2022 has extended support until 2033.
What changes from 2016:
- Compatibility level — an in-place upgrade keeps the compat level intact, which is good. But you do not get newer cardinality estimator improvements until you raise it.
- Deprecated features — run the assessment tooling before migration to surface deprecated syntax.
- TempDB improvements — SQL Server 2019+ configures multiple TempDB data files by default, which often improves concurrency immediately.
- Resumable index operations, accelerated database recovery — real operational gains you get on day one.
Timeline: 4–8 weeks for a careful migration with testing. Side-by-side is safer than in-place for production systems. Since you are already past the deadline, prioritize by exposure rather than trying to move everything at once.
Free · 2 Minutes
Not sure where your migration risk actually sits?
Take the Self Assessment — know your risk before your next audit.
Option 2: Migrate to Azure SQL
If you are on Azure or heading there, Azure SQL Managed Instance is the closest lift-and-shift target for SQL Server 2016.
Advantages:
- Microsoft manages patching, backups, and high availability
- No end-of-life cliff to manage again
- Azure Hybrid Benefit lets you apply existing licenses to reduce cost
- Built-in HA/DR without complex Always On configuration overhead
Gotchas for SQL Server 2016 migrations to Azure SQL:
- SQL Agent jobs — Azure SQL Database has no SQL Agent. Managed Instance does, but it is not 1:1. Inventory your jobs first.
- Linked servers — limited or unavailable. Cross-server queries may need rearchitecting.
- CLR assemblies — only SAFE CLR is supported.
- Distributed transactions — MSDTC is not supported in Azure SQL Database.
- Max database size — Managed Instance General Purpose tops out at 16 TB.
Timeline: 6–12 weeks depending on application complexity. Use Azure Database Migration Service to assess compatibility first.
Option 3: Extended Security Updates (ESUs)
If you genuinely cannot migrate yet, ESUs are the only way to keep receiving security patches — and the clock started on July 14, 2026, whether or not you enrolled.
What ESUs cost:
- Year 1 (July 2026 – July 2027): 75% of your annual license fee
- Year 2 (July 2027 – July 2028): 100% of your annual license fee
- Year 3 (July 2028 – July 2029): 125% of your annual license fee
If you run on Azure, ESUs for SQL Server 2016 VMs are available at no additional cost through Azure Arc-enabled infrastructure.
ESUs are a bridge, not a solution. Coverage ends for good in 2029, and if you enroll late you may have a gap on record that an auditor can see.
Common Migration Gotchas from SQL Server 2016
Cardinality Estimator Behavior Changes
SQL Server 2016 defaults to the new cardinality estimator at compatibility level 130, but many shops migrating from 2012 or 2014 kept the legacy CE via trace flag 9481. When you upgrade and reset compat level, you finally hit the new CE. Some queries speed up, some regress. Test your workload with the Database Experimentation Assistant before cutover.
Deprecated Feature Usage
Run this on your 2016 instance before migration:
SELECT * FROM sys.dm_os_performance_counters
WHERE counter_name = 'Deprecated Features'
AND cntr_value > 0;Any counter above zero is a feature you are using that may behave differently or not exist on a modern engine.
TempDB File Count
Running SQL Server 2016 on 8+ cores with a single TempDB data file usually means allocation contention. Post-migration, match TempDB file count to your logical processor count (up to 8 files).
Always On Availability Groups Upgrade Sequence
Upgrade order matters: secondaries first, then fail over and upgrade the old primary. Never upgrade all nodes at once.
A Realistic 90-Day Recovery Plan
You are past the deadline, so the goal is shortest time to supported, not perfect sequencing.
1. Days 1–10 — inventory, classify by exposure, enroll in ESUs for anything you cannot move quickly
2. Days 11–30 — run DMA/DEA against your highest-risk databases and pick a target per workload
3. Days 31–60 — stand up the target environment, restore, test application connectivity and job schedules
4. Days 61–90 — cut over the high-exposure workloads, then queue the rest on dated waves
Compliance Is the Part You Cannot Defer
Under PCI-DSS v4.0 Requirement 6.3.3, software must be protected from known vulnerabilities. Since July 14, 2026, SQL Server 2016 without ESUs does not meet that bar.
If you are audited today, the question will be direct: are you running unsupported software? The difference between a finding you can defend and one you cannot is whether you can show enrollment in ESUs, compensating controls, and a dated remediation plan.
The Bottom Line
The deadline has passed. That does not mean the risk is fixed or unfixable — it means the work is now overdue and should be scheduled like an incident, not a project.
If you need a second set of eyes on the inventory and the sequencing, that is exactly the kind of work we do.
Related services
Dealing with this in production? Here's how we help.
Cloud Database Migration
On-prem to AWS RDS, Azure SQL, or Cloud SQL — zero data loss, minimal downtime, tested rollback.
24/7 Remote DBA Support
Around-the-clock monitoring, proactive detection, and emergency incident response.
← All posts