SQL Server 2016 End of Life: Upgrade, Azure, or ESU?

If you still have SQL Server 2016 running in production, you have about three weeks before it goes dark. Support ends July 14, 2026, and unlike most “end of life” headlines that vendors recycle every couple of years, this one comes with a real bill attached no matter which way you turn.

I’ve sat through enough of these migrations to know the failure mode: everyone agrees the database is old, nobody owns the decision, and then July arrives, the security patches stop, and your next compliance audit flags an unsupported database engine sitting under your customer data. So let’s get the math right while there’s still time to act on it.

What actually stops on July 14

After that date, Microsoft ships nothing for SQL Server 2016 unless you pay for it. No security patches, no bug fixes, no technical support — across all editions. Enterprise, Standard, Web, Express, the lot. Your instances keep running, of course. SQL Server doesn’t phone home and shut itself off. That’s exactly what makes this dangerous: everything looks fine right up until a CVE drops and there’s no patch coming.

The compliance angle is the part that catches people. Running an unsupported database engine is a finding under SOC 2, PCI DSS, and HIPAA. It’s not a “we’ll note it” finding — it’s the kind that shows up in the executive summary of an audit report and triggers a remediation deadline you don’t control. If you’re regulated, “do nothing” isn’t really an option on the table. It’s a decision to fail your next audit.

The four roads out

Strip away the vendor noise and you have four choices:

Upgrade in place to SQL Server 2022 or the new 2025 release.
Move to Azure — either SQL Managed Instance (PaaS) or SQL Server on an Azure VM (IaaS).
Buy Extended Security Updates as a bridge while you plan the real move.
Do nothing and accept the risk (and the audit findings).

Most of the analysis comes down to one question: how much does buying time actually cost you, and is that money better spent moving forward instead?

The ESU trap, in real numbers

Extended Security Updates are Microsoft’s paid life-support program. They cover critical security fixes only — no features, no non-security bug fixes — and they’re available through July 17, 2029. That gives you a hard three-year runway.

Here’s the catch, and it’s a deliberate one. ESU pricing escalates every year, calculated as a percentage of your original license cost:

ESU Year	Window	Cost (% of license)
Year 1	Jul 2026 – Jul 2027	75%
Year 2	Jul 2027 – Jul 2028	150%
Year 3	Jul 2028 – Jul 2029	300%
Total	3 years	525%

Read that bottom row again. Three years of doing nothing but staying patched costs you more than five times what you originally paid to license the thing. The escalation is intentional — Microsoft isn’t selling you a comfortable parking spot, they’re selling you a cattle prod that gets sharper each year so you’ll actually migrate.

One more eligibility detail that trips people up: ESU is only available for Enterprise and Standard editions. If you’re on Express, Web, or Developer, there’s no paid bridge at all. Your only options are to upgrade or move.

So ESU makes sense in exactly one scenario: you have a genuine, funded migration plan that lands inside 12 months, and you need cover for the gap. Pay for Year 1, get off 2016 before Year 2’s 150% bill hits. Buying ESU with no migration plan behind it is just renting a problem at a 75% markup that doubles next year.

The Azure “free ESU” rumor — kill it now

You’ll read in a dozen places that moving to Azure VMs gets you free ESUs. That was true for SQL Server 2014. It is not true for SQL Server 2016.

For 2016, running on Azure VMs lets you subscribe to ESUs through the SQL IaaS Agent extension, but they aren’t free. And as of the April 2026 pricing consistency update, Microsoft charges the same for ESU whether you buy it inside Azure or outside it — so the old “lift to Azure VM and patch for free” play is gone for this version. If someone on your team is banking on that, correct them before it ends up in a budget deck.

The genuinely version-free option is Azure SQL Managed Instance with the always-up-to-date policy. It’s PaaS, it’s versionless, and end-of-support dates simply stop being your problem because there’s no version to age out. That’s a real escape from this treadmill — but it’s a migration project, not a checkbox, and you don’t have three weeks to do it properly.

Costed comparison

Rough shape of the three serious paths over a three-year horizon, assuming a mid-size shop with a handful of Standard edition cores:

ESU bridge (3 years): 525% of license cost, and at the end you still own the migration. Worst total cost if you ride it the full term. Only rational as a 6–12 month stopgap.
In-place upgrade to 2022/2025: one-time license/Software Assurance cost plus the engineering effort to test and cut over. Your hardware and ops model stay the same. Cheapest if your app is compatible and you have the OS headroom.
Azure SQL Managed Instance: no more license-version anxiety ever, but you’re now paying ongoing compute/storage and taking on a real lift-and-shift. Highest sticker price month to month, lowest long-term maintenance burden, and it kills the EOL cycle permanently.

There’s no universally right answer here, and anyone who gives you one without asking about your app dependencies is selling something. The ESU path looks cheap in Year 1 and becomes the most expensive option by Year 3. The Azure path looks expensive every month and is the only one that ends the recurring migration tax for good.

What actually breaks going 2016 → 2022/2025

Good news first: the jump is smaller than people fear. When you upgrade, your databases keep their original compatibility level unless you change it by hand. So a database sitting at compatibility level 130 (that’s 2016) stays at 130 on a 2022 engine, and the optimizer behaves the way your app expects. You can raise the level later, deliberately, once you’ve tested the new cardinality estimator behavior. This is the single most important knob for a low-drama upgrade — don’t bump compat level and engine version in the same change window.

SSIS is calmer than its reputation too. There are no breaking changes and no behavior changes to Integration Services features going into 2022. The friction is in the tooling around it: SSIS packages carry a version stamp (13.0.0.0 for 2016), and moving them forward means re-targeting the project to the new version — you can’t just drop a 2016 .dtsx onto a 2022 server and expect it to load untouched.

The real landmines are the drivers. The old SQL Server Native Client (SQLNCLI / SQLNCLI11) and the legacy OLE DB provider (SQLOLEDB) are deprecated. Everything should be on the Microsoft OLE DB Driver (MSOLEDBSQL) instead. If you’ve got linked servers, SSIS connection managers, or old application connection strings still reaching for Native Client, that’s where an upgrade quietly falls over. Grep your connection strings and your SSIS configs before you do anything else. The Attunity CDC components for Oracle are also gone in 2022 if you happen to rely on them.

As for 2025 versus 2022: 2025 is the newer engine with the built-in AI and vector features Microsoft is leaning into, but for a straightforward “get off 2016” move, 2022 is the more boring, more battle-tested target. Pick 2025 if you have an actual use for the new capabilities. Otherwise boring wins.

A migration playbook that won’t blow up

Whatever target you pick, the sequence is the same:

Assess first. Run the Data Migration Assistant against your 2016 instances (or Azure Migrate if you’re heading to the cloud). It surfaces deprecated features, breaking changes, and compatibility blockers before they surface themselves at 2 a.m. Don’t skip this because the database “seems simple.” The deprecated-driver problems never show up until you point a tool at them.

Inventory the edges. The database engine is the easy part. It’s the linked servers, the SSIS packages, the SSRS reports, the ETL jobs, and the dozen application connection strings nobody documented that turn a clean upgrade into a week of firefighting. List them now.

Dry run on a copy. Restore a recent backup to a staging instance running your target version, point a test slice of the application at it, and run your real workload. Watch for plan regressions when you eventually raise the compatibility level.

Plan the rollback before the cutover. Take a fresh full backup immediately before you cut over, and write down — actually write down — the exact steps to point the app back at 2016 if the new instance misbehaves. A rollback plan you invent during the incident is not a rollback plan.

Cut over in a window you control, verify, then keep the old instance around (powered off, not deleted) until you’re confident.

Pick your path

A quick decision tree based on the shops I’ve watched go through this:

Small single-instance shop, app you control: in-place upgrade to 2022, keep your compatibility level pinned, fix your drivers, done. Don’t overthink it.
Regulated enterprise: you cannot be sitting on an unsupported engine past July 14. If a clean migration won’t finish in time, buy ESU Year 1 as a bridge with a funded plan behind it, and get to 2022 or Managed Instance before the Year 2 bill lands.
App with heavy or undocumented dependencies: ESU Year 1 to buy breathing room, run the Data Migration Assistant immediately, and treat the dependency untangling as the real project. The database move is the last step, not the first.
Tired of doing this every few years: Azure SQL Managed Instance with the versionless policy. It costs more monthly and it’s a proper migration, but it’s the only option here that means you never read a “SQL Server 20XX end of life” post again.

The one path I’d argue nobody should choose on purpose is riding ESU for the full three years. By the time you’ve paid Year 3’s 300%, you’ve spent more than five times your license cost to delay a migration you still have to do — and you’ve done it while running an engine that’s a year further behind on everything except security patches.

Three weeks isn’t enough to finish a careful migration, but it’s plenty of time to run the Data Migration Assistant against your instances and find out which of these four roads you’re actually on. Start there this week — the assessment is free, and it’s the only thing standing between you and an honest budget number.

Sources: