SQL Server 2016 has weeks of support left. Here's the unemotional version

July 14 is on the calendar. Triage by exposure, pick one of three paths, and put the next date on the calendar before it does this to you too.

On July 14, Microsoft ends extended support for SQL Server 2016.1 If that database is in your environment — and in the mid-market, it very often is, quietly underneath the ERP, the warehouse system, or that application from a vendor who no longer exists — here's the situation without the alarm bells.

Patches. That's it, and that's everything. No more security updates, at any severity, ever. Every vulnerability discovered in SQL Server 2016 from that day forward stays open permanently, because there's no team left writing fixes.

The database doesn't stop working. Nothing dramatic happens on the day — which is exactly why these dates slip past. The change is that your risk starts compounding, silently, and (as we covered in April's piece on insurance renewals) your cyber policy's "maintained systems" language starts working against you.

With weeks rather than quarters remaining, the full migration you should have started in March isn't happening before the date. Fine. What's still entirely doable is making sure the risk you carry across July 14 is deliberate. Sort your 2016 instances into three piles:

First: anything internet-adjacent or compliance-scoped. Instances reachable from outside, holding regulated data, or inside your cyber-insurance attestations. These get action before the date — upgraded, isolated, or enrolled in Extended Security Updates (ESU, Microsoft's paid program that keeps critical patches flowing after regular support ends) — no exceptions.

Second: core internal workloads. The ERP database, the operational systems. Not directly exposed, but business-critical. These need a dated plan, even if execution lands in Q3.

Third: the dev box nobody remembers. Test instances, the reporting server from a retired project. The right answer for many of these is decommissioning — the cheapest migration there is.

All of this, of course, assumes someone can produce the list of instances. If that inventory doesn't exist, building it is the real starting point — and its absence says more about the environment than any single unpatched server does.

Upgrade in place. To a current SQL Server version. Cleanest for workloads you'll keep running on-premises; requires application compatibility testing, which is the long pole — start with the vendor's support matrix, not the installer.

Replatform to a managed database. If the workload was headed to the cloud eventually, this deadline is a serviceable excuse. The migration is more work up front; the patching treadmill goes away permanently.

Buy the bridge. Extended Security Updates exist for SQL Server too — at roughly 75% of the license cost, per year, escalating.2 As we said about the Windows 10 version of this decision: a bridge is a fine thing to buy and a poor thing to live on. ESU with a dated exit is a plan; ESU without one is an expensive way to not decide.

This keeps happening — Windows 10 in October, SQL Server now, and Windows Server 2016 already queued up for January 12, 20273 — for one reason: nobody owns the calendar. The dates are published years ahead. The migrations have knowable durations. Which means every one of these has a start-by date that can sit on an executive calendar next to the board meetings and the renewal deadlines.

Windows Server 2016's start-by date, for most environments, is now — this quarter, not next. That's the entire reason EOL Radar exists: the products mid-market stacks most commonly run, their dates, and the honest math on when you'd need to begin. (New to the vocabulary? The plain-English guide takes seven minutes.)

Put the calendar in front of whoever owns the budget. The unemotional version of every one of these deadlines is available months in advance — but only on that side of the date.