Could you say, without checking, which version of SQL Server your main business application runs on? If the answer turns out to be 2016, there’s a date to plan around: mid-July 2026, when Microsoft’s lifecycle page lists extended support as ending at 6:59:59 AM on 15 July. Microsoft’s Azure documentation gives 14 July 2026 as the start of the first Extended Security Updates year, so the exact moment depends on the time zone, and it’s the month that matters for planning. Nothing stops working that day, which is exactly why it’s easy to ignore.
What changes in mid-July
Mainstream support for SQL Server 2016 ended in July 2021, and since then extended support has meant security updates and nothing else. Service Pack 3, the last service pack, has the same end date, so being fully patched on it doesn’t buy extra time. After that date Microsoft describes the product as no longer receiving servicing or support.
The database carries on running. What changes is that without Extended Security Updates, any flaw discovered from then on has no official fix waiting for it, and even with them Microsoft’s updates cover only flaws it rates Critical (more on that below). How much that matters depends on where the server sits. One that only your application server can reach is a different proposition from one that’s exposed to the internet or shared with other systems. It’s also worth checking what your own policies and your customers’ contracts say about running unsupported software, because they can settle the matter before any technical argument does.
Start by finding out what you have
Before choosing a route you need four answers, and none of them should need a database administrator to answer. Which SQL Server version and edition is it, and is it on Service Pack 3? Which application depends on it? Where does it run, and on which version of Windows Server? And does the supplier of that application support a newer SQL Server?
That last question carries the most weight. It’s the supplier’s word on compatibility that tells you which routes are open, so ask for it in writing. A route that looks cheap and tidy on paper can fall over on one unanswered question about the application.
Buying time with Extended Security Updates
If you can’t move yet, Microsoft offers Extended Security Updates (ESUs) for up to three years after support ends. The lifecycle page has the first year running from 15 July 2026 to 13 July 2027, with the third ending in July 2029.
How you get them depends on where the server runs. For an on-premises server you connect the instance to Azure Arc, which is free of charge, and then either hold Software Assurance under certain Microsoft agreements or switch on a pay-as-you-go option that doesn’t need it. Azure bills hourly and you can cancel at any time, and the subscription ends automatically when you upgrade or move to Azure. If a server can’t be connected to Arc, you may be able to buy through volume licensing by speaking to your Microsoft account team.
Be clear about what you’re buying, because it’s less than support. ESUs cover only flaws rated Critical by the Microsoft Security Response Center, and there’s no regular schedule because an update appears only if one is needed. You don’t get new features, bug fixes or customer-requested changes. Help is limited to problems with the updates themselves. Microsoft’s general ESU guidance puts the cost at roughly 75% of the on-premises licence price each year, but its page for 2016 says the price structure differs and gives no figure, so don’t budget from the 75% and get a current quote instead. And if you’ve only ever applied the security-only (GDR) updates, install and test the most recent cumulative update when you subscribe, not when the first ESU turns up.
We’d treat ESUs as a bridge with a known end, not a place to live. If you’d rather have an arrangement in place before the date than after, start the subscription conversation early.
Moving to a newer SQL Server
Upgrading puts you back inside a supported lifecycle. Microsoft’s table lists SQL Server 2017, 2019, 2022 and 2025 as targets, with extended support ending (approximately) in 2027, 2030, 2033 and 2036 respectively. We’d go as new as your application supplier allows, because 2017 only buys another year or so.
The worry is usually whether the application will behave. Microsoft states that if a database keeps its older compatibility level, existing applications are protected from functional and performance changes, and full recertification is needed only when the application requires features of a newer level. Treat that as a starting point to test with your supplier, not a guarantee. The migration component in SQL Server Management Studio and the Query Tuning Assistant can help spot problems.
The costs are real. You buy licences and possibly hardware and there may be downtime, while an in-place upgrade carries a risk of things going wrong part-way. If the server’s Windows version is too old for the newer SQL Server, you may need to upgrade that too, and building a new server beside the old one is the safer route, though it costs more. Whatever you choose, make sure you’ve got a restore you’ve tried, which is the point of our backup strategy guide.
Moving to Azure
Two of Microsoft’s Azure routes suit most business applications. SQL Managed Instance is a managed service that closely resembles a SQL Server instance and which Microsoft describes as always running the latest features when set to its Always-up-to-date update policy, so end of support doesn’t apply. It has some Transact-SQL and feature differences, and requires an ExpressRoute or VPN Gateway connection to reach it from your network.
SQL Server on an Azure virtual machine can be moved across as it is, with ESUs subscribed to, or upgraded as part of the move. Free ESUs for moving to Azure apply to SQL Server 2014 only, not 2016. You also still look after the operating system and SQL Server yourself, as you would on your own hardware.
Neither is a quick fix if the application stays in your office while the database moves to Azure, because the connection between them, sign-in and speed all need thinking through first.
Which route fits
It mostly comes down to three questions. If the supplier supports a newer version, plan an upgrade and use ESUs only as a short bridge; if not, ESUs buy time while you push the supplier or look for a replacement. The more exposed the server is, the less comfortable it is to wait. And if the hardware or Windows version is near its end too, moving to a new server or to Azure while you upgrade saves doing the job twice.
Our continuing support page covers how we arrange ongoing help with business systems generally. On the database side we’re a consultancy that advises on the decision, not a service that runs your database day to day.
If you’ve worked through those questions and still can’t tell whether to upgrade, move or buy time, or you’d like the reasoning checked before money is committed, talk to us and we’ll go through it with you.
