Extended support for SQL Server 2016 ended on 15 July 2026. If you are reading this in the months after that date with instances still running it, you are not unusual and you are not out of options — but the options have narrowed, and one of them now costs money it did not cost before.
This article is about the decision. If you want the detail of what end of support means and how to inventory your estate, the SQL Server 2016 end of support page covers that.
What actually changed on 15 July 2026
One thing: Microsoft stopped shipping security updates. Nothing broke. Your instances did not stop working, no licence expired, and no feature switched off. That is precisely what makes this risk easy to defer — there is no outage to force the issue.
What accumulates instead is unpatched vulnerabilities. Every SQL Server vulnerability disclosed after that date stays open on a 2016 instance permanently. The exposure compounds rather than sitting still, and it does so quietly.
For most Australian organisations the sharper edge is not technical. It is the contractual and regulatory one: an unsupported database engine holding personal information is difficult to defend under the Privacy Act's security requirements, and for APRA-regulated entities, CPS 234 asks you to maintain information security capability commensurate with the threat. Insurers and enterprise customers increasingly ask the question directly in due-diligence questionnaires. Being the vendor who has to answer "no, it is unsupported" is a commercial problem before it is a security one.
Option 1: Extended Security Updates
This is the option most organisations do not realise they have. Microsoft sells Extended Security Updates for SQL Server 2016 in yearly blocks, and the schedule runs further than most people expect:
- ESU Year 1 — 15 July 2026 to 13 July 2027
- ESU Year 2 — 14 July 2027 to 18 July 2028
- ESU Year 3 — 19 July 2028 to 17 July 2029
ESU delivers security updates rated Critical and Important. It does not include feature updates, and it does not include general technical support for problems unrelated to those patches.
It is worth being honest about what ESU is for. It is a bridge, not a destination — it buys a planned migration the time to be planned properly rather than done badly over a weekend. Three years sounds generous, and organisations that treat it as three years of not thinking about the problem arrive at July 2029 in exactly the same position with fewer options and no further extensions.
ESU is free for SQL Server 2016 instances running in Azure — on Azure Virtual Machines, Azure VMware Solution or Azure Stack. That asymmetry is deliberate on Microsoft's part, and it changes the arithmetic for anyone already part-way to Azure.
Option 2: Upgrade in place, or side by side
The obvious answer, and usually the right one. The question is which version, and the answer is less obvious than it looks.
SQL Server 2022 is supported until 12 January 2033, with mainstream support running to 12 January 2028. That is the longest runway available on a released version and the default recommendation for most estates.
SQL Server 2019 is still supported until 9 January 2030 — but its mainstream support ended on 1 March 2025, so it is already in extended support today. It receives security updates and nothing else: no feature updates, no design changes, no free support incidents. Choosing 2019 in 2026 means deliberately landing on a version that is already past half its life. It is occasionally the right call when a third-party application is certified against 2019 and not 2022, and it is rarely the right call for any other reason.
The work itself is rarely the engine upgrade. On the estates we review, the effort sits in three places: deprecated features that a 2016-era application still uses, compatibility level changes that alter the query optimiser's behaviour and therefore your execution plans, and third-party software whose vendor support matrix has not kept up. None of those are discovered on cutover night if the project includes a dry run against a copy of production, and all three are discovered on cutover night if it does not.
Option 3: Move to a managed platform
If you are going to touch every instance anyway, it is a reasonable moment to ask whether you should still be patching database servers at all.
Azure SQL Managed Instance is the closest managed equivalent to a SQL Server instance — it keeps SQL Agent, cross-database queries, linked servers and the instance-level surface that a lift from 2016 usually depends on. It is evergreen, so the end-of-support conversation does not recur.
Azure SQL Database is a smaller unit and a bigger change: no SQL Agent, no cross-database queries, and application changes that a 2016-era codebase will feel. It suits a single application database and suits a consolidated estate poorly.
The honest caveat is that a managed platform moves cost from capital to operating expenditure and from licences to a monthly bill. That is an improvement for some organisations and a budgeting problem for others. It is worth modelling before it is worth deciding.
Option 4: Accept the risk, in writing
Sometimes the instance is a reporting copy behind three firewalls, holds nothing personal, and is scheduled for decommission in six months. Spending a migration budget on it would be poor judgement.
If that is the call, make it a decision rather than a drift. Write it down, name the compensating controls — network isolation, restricted authentication, monitoring — put a review date on it, and have someone accountable sign it. A documented risk acceptance is a defensible position. An undocumented one is indistinguishable from not having noticed, which is the position you least want to be in if the question is ever asked by a regulator, an insurer or a customer.
How to decide
The decision is usually made per instance rather than per estate, and it turns on three questions:
- What does this instance hold? Personal information, payment data or anything contractually protected moves the instance to the front of the queue regardless of how convenient it is to leave alone.
- What can reach it? An instance reachable from an application that is reachable from the internet is a different risk from one on an isolated management network.
- What does the application vendor support? This constrains the answer more often than anything technical, and it is the question that most often turns a simple upgrade into a project.
Most estates end up with a mix: a handful of instances upgraded quickly, a few covered by ESU while a larger application project runs, and one or two documented as accepted risk pending decommission. A plan that puts every instance in the same bucket is usually a plan that has not been tested against the estate.
Where to start
Start with an inventory, because almost nobody has an accurate one. You need version and build per instance, what each database supports, who can reach it, and what the application vendor certifies. Our free 20-point health check produces most of that for one instance from scripts you can read before you run them, and you keep the output whether or not you engage us.
If you would rather talk it through, our consultants are in Australia and so is every DBA who would touch your instances. Ask us what your options look like — including when the answer is that you have less to do than you feared.