SQL Server 2016 is out of support: pay for ESU, upgrade or migrate?

SQL Server 2016 reached the end of extended support on 14 July 2026, and since then it receives no security patches. Microsoft marked the date on its SQL Server blog after ten years of support, and the lifecycle page leaves no room for interpretation. Without an Extended Security Updates (ESU) subscription, the next critical engine vulnerability will have no fix for that version.

In mid-sized and large Latin American companies, SQL Server 2016 often sits under the ERP, the payroll or the loan book, wired to integrations nobody wants to touch. Standing still stopped being an option. There are three exits — pay for ESU, upgrade the engine, or move to a managed service — and each one hides a trap worth seeing before you sign anything.

What exactly did SQL Server 2016 stop receiving?

Every patch. Microsoft’s Fixed Lifecycle Policy gives five years of mainstream support and five of extended support; once extended support ends, there are no patches or security updates. There is no technical support either: you cannot log a ticket even with an active support plan; with ESU, only for issues with those updates.

For an ISO 27001 auditor or a financial regulator, that becomes a concrete finding: an asset processing sensitive data runs on software with no vulnerability fixes. A third-party application control tool does not cover it either; Microsoft’s own FAQ states it is no replacement for product security fixes.

What do ESUs cover, and for how long?

ESUs are a paid bridge of up to three years, in annual terms Microsoft publishes on the product lifecycle page: year 1 runs from 15 July 2026 to 13 July 2027, and the last one ends on 17 July 2029. What they include is narrower than most people assume:

• Only security updates rated Critical by the Microsoft Security Response Center (MSRC), and only if and when they appear. There is no monthly cadence.
• No new features, functional improvements or customer-requested fixes.
• Enterprise and Standard editions only. Express, Web and Developer cannot subscribe.
• The latest service pack is mandatory (SP3 for 2016): Microsoft only produces updates that apply on top of it.

That last point is the one teams discover late. If you only applied GDR updates for years, Microsoft recommends installing and validating the latest cumulative update when you subscribe, not on the day the first critical patch lands. Validating a cumulative update in a hurry, on the ERP server, is exactly the situation ESU was supposed to avoid.

How are ESUs purchased, and why does waiting save nothing?

With Software Assurance under an Enterprise Agreement, EAS, SCE or EES, you buy them through volume licensing. Without Software Assurance, the options are migrating to Azure or connecting the instance to Azure Arc — connecting is free — and turning on pay-as-you-go billing. Servers at a third-party hosting provider go through Arc as well.

Three billing details change the maths:

• Billing is per virtual core, with a four-core minimum per virtual machine. Across a fleet of small VMs, that minimum weighs more than the real size.
• Billing started at midnight UTC on 15 July 2026. Subscribing later adds a one-time bill-back charge to the first day of the term. Delaying the decision does not shrink the invoice; it only leaves months without patches.
• A change in the VM identifier — rebuilding, cloning or moving the VM to new hardware — makes Arc treat it as a new machine and can result in double billing. Before touching the VM, unsubscribe on the original machine and subscribe the new one afterwards.

And one difference from SQL Server 2014 that many budgets carry over by mistake: with 2014, lifting the instance as-is to an Azure VM gave you free ESUs. With 2016 that no longer applies: on Azure you pay for them too.

Can I upgrade SQL Server on the same server?

It depends on the operating system, and that is where most plans break. SQL Server 2025 supports a direct upgrade from 2016 SP3, but it requires Windows Server 2019 or later. A SQL Server 2016 instance built in 2017 or 2018 often runs on Windows Server 2016, and on that server an in-place upgrade is not possible.

On top of that, Windows Server 2016 loses its own extended support on 12 January 2027. Upgrading only the engine, if it were possible, would leave the server out of support four months later.

From an operations standpoint, this is an advantage. The route we use is a side-by-side migration: a new server with Windows Server 2022 or 2025 and the new SQL Server version, with databases restored from backup or kept in sync through log shipping until the cutover window. The old server stays untouched, so as long as no writes have landed on the new one, rolling back means pointing connections back. Two expiry dates get solved in a single project.

Which version should you jump to?

The one that buys the most years for the same effort. Migrating costs roughly the same towards any version; what changes is when you have to do it again:

• SQL Server 2017: extended support until October 2027. Thirteen months of breathing room.
• SQL Server 2019: until January 2030, and its mainstream support already ended in 2025.
• SQL Server 2022: until January 2033.
• SQL Server 2025: until January 2036.

If you run on Amazon RDS, the decision is half made for you. AWS stopped allowing new SQL Server 2016 instances on 15 January 2026and schedules the remaining ones to migrate to SQL Server 2019. That automatic migration fixes today’s expiry and sets up another one for 2030, on a date the provider picks rather than your team. Run it yourself instead, towards 2022, with testing beforehand.

SQL Server 2025 also brings a licensing change worth a spreadsheet: Standard edition goes up to 32 cores and 256 GB of buffer pool per instance and gains Resource Governor. Some companies pay for Enterprise purely for memory; with those limits, part of that spend may stop being justified. Web edition is discontinued.

What breaks when you upgrade to SQL Server 2025?

Microsoft publishes a list of breaking changes, and nearly all of them share one cause: the OLE DB 19 driver ships stricter encryption defaults and expects a trusted certificate. What fails:

1. Linked servers. Existing configurations may stop connecting unless a valid certificate is in place.
2. Replication with a remote distributor. Data keeps replicating, but changes to the publication, Replication Monitor and agent status all fail.
3. Remote log shipping monitoring, when the monitor runs 2025 and the rest of the topology runs an earlier version.
4. Full-text search. After an in-place upgrade, queries against existing indexes fail because 2025 removes the legacy word breakers and filters. Those indexes need rebuilding or recreating.

The right fix for the first three is issuing certificates from an internal or public CA before the window, not flipping TrustServerCertificate to get through the night. The certificate takes a week to prepare. The linked server nobody documented shows up on the Monday after cutover, with payroll reconciliation stalled.

Whole components leave too. Data Quality Services and Master Data Services are discontinued, and with DQS installed the upgrade fails. Reporting Services gets no new releases: on-premises reporting moves to Power BI Report Server, which accepts the same RDL files and installs with a SQL Server 2025 Standard or Enterprise key. If your SSRS 2016 lives on the same server as the database, that migration joins the plan.

How do you keep performance from shifting after cutover?

By separating two risks that usually get mixed: changing the engine and changing the optimizer. A database restored on a newer version keeps its compatibility level, and SQL Server 2025 accepts levels 100 through 170. The database can arrive at SQL Server 2016’s level 130 and keep the optimizer behaviour it already knew.

The order we follow: migrate at level 130, turn on Query Store, let a full business cycle run — a month-end close, not a weekend — and only then raise the compatibility level, comparing plans against the captured data. Microsoft documents that workflow and offers the Query Tuning Assistant to support it. If a query regresses, one ALTER DATABASE statement takes you back to the previous level without touching the migration.

What about moving to a managed service instead?

For many workloads it is the exit that avoids repeating this exercise in 2033. Azure SQL Managed Instance offers, per Microsoft’s ESU FAQ, nearly 100% compatibility with on-premises SQL Server, built-in high availability and a version-less model: patching and upgrades stop being a project. For customers without Software Assurance, it is the option Microsoft recommends. It supports compatibility levels from 100 upwards, so the migrate-at-130-then-raise strategy works the same way.

The limit lies in whatever is not database: Agent jobs calling local executables, SSIS packages with network paths, integrations through shared folders. That is the first thing to inventory, because it decides whether the workload fits a managed service or needs a VM.

Where we would start this week

1. An inventory per instance: version, edition, service pack, operating system, linked servers, replication, full-text, SSRS, DQS and MDS. SERVERPROPERTY and the system views cover it in an afternoon.
2. One destination per instance, not one for the whole fleet: managed service, a new VM on 2022 or 2025, or ESU as a bridge.
3. If there is ESU, a written exit date. A bridge without a date turns into a recurring cost until 2029.
4. Certificates before the window for everything connecting through OLE DB 19.
5. A restore rehearsal on the new server, with real data and measured timings. That number defines the cutover window.

How we help at Athrun Data Intelligence

A 30-minute call to review your SQL Server inventory and tell you which instances should move now, which can wait on ESU and which fit a managed service. If it fits, we run the side-by-side migration with rollback ready, and raise the compatibility level only when the Query Store data backs it.