SQL Server 2016 is out of support. Here is what to do about it.
Extended support ended on 14 July 2026. The instances still run, which is exactly why they get forgotten. This guide sets out the four options, what each one costs you in risk, and how to move the data layer without stopping the business.
- Extended support ended 14 July 2026
- Windows Server 2016 follows on 12 January 2027
- Paid Extended Security Updates run for up to three years
- Analytics and ETL workloads can move first and shrink the problem
- Legacy keeps running until the new platform reconciles
What ended, and what did not
Mainstream support for SQL Server 2016 ended in July 2021. Extended support, which still delivered security patches, ended on 14 July 2026. From that date Microsoft issues no fixes for newly found vulnerabilities unless you pay for Extended Security Updates.
Nothing switches off. Backups run, applications connect, reports refresh. That is the problem. An unsupported database that keeps working looks fine right up to the day a critical vulnerability is published and your instance is the one that does not get the patch. Microsoft has said publicly that SQL Server 2016 is still heavily deployed, so you are not alone, but that is not a defence an auditor or a cyber insurer will accept.
Windows Server 2016, the host under many of these instances, reaches its own end of support on 12 January 2027. Many estates have the database and the operating system expiring within six months of each other, which is a reason to plan both moves together rather than twice.
The four options, honestly compared
Most organisations end up combining two of these. The mistake is treating the whole estate as one decision.
Extended Security Updates
Buy up to three years of security-only patches from Microsoft. The price rises each year and ESUs cover security, not bugs or features. Right for a system that is already scheduled for decommissioning on a known date. Wrong as a substitute for a plan.
Upgrade in place to SQL Server 2022 or 2025
A side-by-side or in-place upgrade on current hardware. The cheapest route for plain transactional application databases. It does nothing for the SSIS, SSAS and Reporting Services estate around them, which is on its own deprecation path.
Azure SQL Managed Instance or SQL on Azure VMs
Keeps T-SQL compatibility and moves patching to Microsoft. Azure VMs have historically included free Extended Security Updates for out-of-support SQL Server, which buys time while the real modernisation happens. Check the current terms for 2016 before relying on it.
Modernise the data layer onto Microsoft Fabric
For warehouses, ETL and reporting, end of support is the moment to stop maintaining a 2016-era BI stack. Fabric replaces SSIS, SSAS and the reporting warehouse with one platform that AI tooling can reach. The application databases that remain are then a much smaller upgrade.
How we sequence it
Inventory everything. Every instance, including the SQL Express editions embedded in line-of-business applications and the reporting server nobody owns. Each is rated by support status, data sensitivity and the workloads that depend on it.
Split transactional from analytical. Application databases need a supported engine with the same behaviour. Warehouses, ETL and cubes need a modern platform. Treating them as one migration is how programmes overrun.
Move analytics first. Building the new data layer on Fabric or Databricks beside the old warehouse shrinks what must be upgraded in place, and it is the part the business feels least when it moves, because the legacy reports keep running throughout.
Reconcile, then cut over. Old and new run side by side through at least one full reporting cycle. Row counts, totals and report outputs are compared before anyone depends on the new platform. Rollback stays available. Then the 2016 instance is decommissioned, with evidence.
This is the same four-stage method we use for every modernisation. See how staged modernisation works.
What this has to do with AI
The board wants AI on operating data, and the operating data is in a 2016 warehouse fed by SSIS packages written a decade ago. Models cannot reach it, lineage cannot be proven, and from 10 December 2026 the Privacy Act requires you to disclose automated decisions that use personal information. End of support is an unglamorous reason to fix the foundation, but it is the one that gets budget approved. Once the data layer is modern, the AI use cases follow quickly.
The questions you're already asking
Can we keep running SQL Server 2016?
Do we need to upgrade Windows Server 2016 at the same time?
What about Reporting Services and SSIS packages?
How long does this take?
Find out which of your SQL Server instances are exposed, and what to move first.
The Legacy-to-AI Readiness Assessment inventories every instance, rates it by risk, and gives you a sequenced plan with dates. Fixed scope, fixed price, no obligation to continue.
Legacy-to-AI Readiness Assessment
Fixed scope. Everything delivered is yours to keep.
- Duration
- 2 to 3 weeks
- Delivers
-
- System and data risk map
- Deadline exposure: end-of-support and policy dates that touch your systems
- Sequenced modernisation plan
- 2 to 3 AI use cases for the next 90 days
- Executive readout
- Price
- Fixed, quoted up front
- Commitment
- None beyond the assessment