On 14 July 2026, SQL Server 2016 reached the end of extended support. From that date Microsoft stopped releasing security updates for it, unless you pay for Extended Security Updates. SQL Server 2017 follows on 12 October 2027. If a line-of-business application was installed on one of these versions and never moved, now is the time to plan what happens next.
Upgrades and migrations are part of our database administration work. This article covers the dates, what end of support actually means, and the three ways forward.
The dates that matter
These come from Microsoft’s published lifecycle pages, which list dates in US Pacific time:
- SQL Server 2016: extended support ended 14 July 2026.
- SQL Server 2017: extended support ends 12 October 2027.
- SQL Server 2019: mainstream support ended 28 February 2025; extended support ends 8 January 2030.
- SQL Server 2022: mainstream support ends 11 January 2028; extended support ends 11 January 2033.
Mainstream support covers fixes and improvements. Extended support covers security updates only. After extended support ends, there are no fixes of any kind without a paid arrangement.
What end of support means in practice
The database keeps running. Nothing switches off. What changes is risk:
- New vulnerabilities are not fixed, so the server becomes easier to attack over time. The php2shell PHP vulnerabilities showed the same pattern: supported PHP versions got a fixed release, while end-of-life versions did not.
- Insurers, auditors and government buyers may ask about unsupported software, and the Essential Eight patching strategies expect it to be removed or replaced.
- Application vendors may stop supporting their software on an unsupported database version, which can leave you without help when something breaks.
Option 1: upgrade to a supported SQL Server version
Moving to SQL Server 2022 or later keeps the database on your own servers or VMs with years of support ahead.
- Check the application first. Confirm with the software vendor which SQL Server versions they support. This is often the deciding factor.
- Prefer side by side to in place. Build the new version on a new server, restore a copy, test the application against it, then cut over. The old server stays untouched as a rollback path.
- Use compatibility levels. An upgraded database can keep its previous compatibility level so query behaviour does not change on day one, then be raised once testing is complete.
Option 2: move to Azure SQL
Azure SQL Database and Azure SQL Managed Instance are platform services: Microsoft keeps the database engine current, so there is no version end of support to plan around again.
- Azure SQL Managed Instance is the closer match for existing SQL Server workloads, with features such as SQL Server Agent jobs and cross-database queries.
- Azure SQL Database suits newer or simpler applications that do not depend on instance-level features.
- SQL Server on an Azure VM is a third route. It moves the server, not the lifecycle: you still choose and upgrade the SQL Server version yourself.
Both platform services run in Australian regions, which keeps data residency straightforward. As with any migration, plan the cutover with a tested rollback.
Option 3: buy time with Extended Security Updates
Extended Security Updates (ESUs) keep critical security fixes coming for up to three years after the end of support. Microsoft is clear about the limits:
- ESUs are paid. For SQL Server 2016 they are no longer free when the server runs on an Azure VM.
- They are obtained by connecting the server to Azure Arc or, for SQL Server on Azure VMs, through the SQL IaaS Agent extension. Servers that cannot connect to Arc may qualify through volume licensing.
- They include critical security fixes only: no new features, no functional improvements and no other fixes.
ESUs are a bridge, not a destination. They make sense when an upgrade is planned but cannot happen before the deadline.
How to choose
A short set of questions usually settles it:
- Which SQL Server versions does the application vendor support?
- How much downtime can the cutover take, and when?
- Does the workload need instance-level features, or would Azure SQL Database suit it?
- Who will look after the database afterwards, and do they have the skills for the platform you choose?
What to do this quarter
- List every SQL Server instance and its version.
SELECT SERVERPROPERTY('ProductVersion')on each instance is a quick start. - Ask each application vendor which versions and platforms they support.
- Pick a path for each instance, and plan a side-by-side upgrade or migration with a rollback. Use ESUs only to cover the gap.
If you would like a second pair of hands, start with a database health check, which includes version and support-lifecycle status for each instance.