SQL Server 2016 End of Support: ESU, Upgrade, or Azure SQL

14 July 2026 was the end of extended support for SQL Server 2016 on every platform: on-premises, on Azure VMs, on Azure VMware Solution and in other clouds. Microsoft stopped producing security updates for it through the normal channel. Nothing switched off, and the servers will keep running for years if you let them.

The exposure is narrow but real. When the Microsoft Security Response Center rates a new SQL Server vulnerability Critical, a supported instance gets a fix and an out-of-support one does not. That gap is what auditors, cyber-insurance questionnaires and customer security reviews ask about — which is why an unsupported database engine shows up as a finding long before it shows up as an incident.

Microsoft's answer for organizations that cannot move immediately is a paid subscription to Extended Security Updates, which protects an instance for up to three years past end of support. For SQL Server 2016, Microsoft's ESU FAQ puts the close of that window at 17 July 2029 — just under three years from today. It is a bridge with a published expiry date, not a reprieve. The other dates worth having on one page are on our Microsoft deadlines list.

The right path is usually decided by the application in front of the database, not by the database itself. Upgrade the instance in place to SQL Server 2022 or 2025. Migrate the databases to Azure SQL Managed Instance or Azure SQL Database, where there is no end-of-support date to plan around. Move the server as-is to an Azure VM and upgrade later. Subscribe to Extended Security Updates and stay put on a dated bridge. Or retire the instance, because a fair number of 2016 instances are still running for a report nobody opens.

Doing nothing is the sixth option, and it deserves an honest price. It costs nothing until the first Critical vulnerability lands, and then it costs whatever the incident or the failed audit costs. It also quietly removes your choices: the estate nobody has inventoried is the one that enrolls in ESU at the last minute and pays a bill-back for the months it waited.

One estate usually carries several answers at once. If you want a target chosen per instance — with the migration method, the blockers and a fixed written quote attached — that is what our SQL Server to Azure Migration Assessment produces in three business days.

ESU for SQL Server 2016 is an Azure subscription attached to the instance, not a product you buy once. Outside Azure — on-premises, at a hosting provider, in another cloud — the route is Azure Arc: install the Connected Machine agent on the host, let the Azure extension for SQL Server discover the instances, and turn the ESU subscription on for each one. Connecting a server to Azure Arc is free of charge; the ESU subscription is the paid part. If Arc is not already in place, that onboarding is a project of its own — the same one that gives you inventory, patching and policy across the servers that are never moving: Azure Arc Hybrid Server Management Implementation.

The meter decides most budgets. It is Microsoft's charge, metered hourly and billed to your Azure subscription, and it is yours: usage counts every core visible to the operating system environment, with a minimum of four cores per environment, and Standard edition is capped at 24 cores. Where several out-of-support instances sit on a few hosts, a physical-core ESU license covering a minimum of 16 physical cores can cover unlimited virtualization on those hosts instead. Enrolling late does not save money: billing began at midnight UTC on 15 July 2026, and subscribing after that triggers a one-time bill-back to the first day of the ESU term.

Eligibility is a licensing fact, not a portal setting. You need active Software Assurance or a SQL Server subscription, or you use the pay-as-you-go license type through Azure, which meters the SQL Server license itself on top of the ESU charge; a perpetual license without Software Assurance, and a Server+CAL license, are not eligible. Express, Web and Developer editions cannot be enrolled at all.

Two limits catch people out. Moving a 2016 instance onto an Azure VM does not make its ESU free — Microsoft changed that price structure for 2016, and the free-ESU benefit applies to SQL Server 2014. And Azure Arc is not currently supported for SQL Server 2016 in Azure Government regions, so those instances go through volume licensing and a disconnected registration.

What ESU delivers is narrower than most people assume: updates for vulnerabilities MSRC rates Critical, released only when one exists, cumulative with the latest cumulative update — so install that update when you subscribe rather than waiting for the first ESU. No new features, no bug fixes, no support contract. Microsoft prices ESU at approximately 75% of the on-premises license cost per year, which is the strongest argument for pairing every ESU decision with a dated exit.

This is the least expensive path when the application allows it. Microsoft's supported upgrade matrix takes SQL Server 2016 at Service Pack 3 or later straight to SQL Server 2022 or SQL Server 2025 — but the host operating system decides which. SQL Server 2022 installs on Windows Server 2016 or later; SQL Server 2025 requires Windows Server 2019 or later. So a 2016 engine on a Windows Server 2016 host can reach 2022 in place, while reaching 2025 means dealing with the operating system first.

That is not a detour. Windows Server 2016 leaves extended support on 12 January 2027, about four months from now, so on many hosts both clocks are already running. Doing the database and the operating system as one piece of work is usually cheaper than doing them twice, and it is one outage window instead of two.

What you buy is time on a published lifecycle: extended support runs to 2033 for SQL Server 2022 and 2036 for SQL Server 2025, per Microsoft's lifecycle table. What you accept is that an in-place upgrade overwrites the instance — a database opened by the newer engine cannot be attached or restored back onto SQL Server 2016 — so rollback means restoring the pre-upgrade backup, and takes as long as that restore takes.

Reporting Services does not come along for the ride. SSRS has been a standalone product since 2017, so SQL Server Setup will not upgrade a 2016 report server in place, and SharePoint-integrated Reporting Services has no path past 2016. Those estates move separately, usually to Power BI or Power BI Report Server.

Migrating to Azure SQL removes the deadline instead of moving it: Managed Instance and Azure SQL Database are fully managed services that do not reach end of support, which is the honest argument for them.

Azure SQL Managed Instance is the closest match to an instance you already run: SQL Agent jobs, cross-database queries and most instance-scoped objects survive the move, and cutover is a failover measured in minutes rather than a restore proportional to your data. Azure SQL Database is the most managed of the targets and usually the least expensive, and also the one that most often needs application changes — Agent jobs, linked servers and cross-database queries have to be rebuilt somewhere. SQL Server on an Azure VM moves the workload as-is with no compatibility work, which is why datacenter-exit programs reach for it; just remember that a SQL Server 2016 instance sitting there still subscribes to ESU and still pays the meter.

If the SQL estate is part of a wider move off physical or VMware hosts, do the sizing and dependency work once across everything — that is Azure Migrate discovery and assessment — and let the per-instance target come out of the SQL assessment.

An estate with SQL Server 2016 instances almost always has SQL Server 2017 instances too, and those come off extended support on 12 October 2027 — about thirteen months from now. Microsoft's SQL Server documentation gives 2027 as the extended-support year; the product lifecycle page gives the day.

Plan them as one program. The upgrade targets, the Azure targets and the application-owner conversations are the same. Running both at once means one round of vendor support questions, one test cycle per application and one change-approval process, instead of repeating the whole exercise next year.

Inventory first, and be specific: instance name, edition, version and service pack level, host operating system, and the applications that connect. Edition matters more than usual, because Express, Web and Developer instances cannot be enrolled in ESU and need a different answer.

Then check the licensing position, because it decides whether ESU is available without the pay-as-you-go route. Then ask each application vendor, in writing, which SQL Server versions they support today — that answer, not your preference, sorts most instances into upgrade or bridge. Then decide per instance with a date attached, and enroll whatever needs ESU sooner rather than later, since the bill-back removes any advantage in waiting.

The wall is 17 July 2029. Three years sounds generous until it is divided across an inventory, a vendor round, a test cycle per application and a change window per instance.