Microsoft retires SQL Server 2016 on July 14, 2026, about five weeks from when we’re publishing this. Nothing dramatic happens on July 15. Your databases keep accepting connections and your jobs keep running. What stops is the patch supply. Every security vulnerability found in SQL Server 2016 after that date stays open on your servers, permanently, unless you pay for the privilege of fixes.
You have four realistic moves: buy extended security updates (ESUs), upgrade in place to SQL Server 2022, rehost the workload in Azure where the ESUs come free, or use the deadline as the push to finally move to PostgreSQL. Each one is defensible for a specific situation. Picking none of them is also a choice. It’s just the one your auditor gets to price for you later.
SQL Server 2016 end of support
We’re gmware, a software engineering firm with our US office in Austin, TX and delivery centers in Bangalore and Mohali, India. End-of-support migrations are standing legacy modernization work for us. Below: what actually changes in July, the ESU price curve (worse than most people expect), a four-option comparison, and a 60-day plan if you’re starting from zero this week.
What changes in July 2026
The engine keeps working; the safety net disappears. After July 14, 2026, Microsoft ships no more security updates for SQL Server 2016. No patches, and no support cases either. (Brent Ozar has been running the public countdown since spring, so this deadline isn’t sneaking up on anyone.) The risk doesn’t arrive as an event. It accrues. Each new vulnerability that applies to the 2016 codebase becomes a permanent hole in your estate, and attackers read the patch notes of newer versions to find exactly those holes.
The second-order effects bite sooner than a breach does. Compliance frameworks expect supported, patchable software, so an end-of-support database is an automatic finding in most audits. Cyber-insurance questionnaires now ask about end-of-life software in plain English. So does every customer security review your sales team forwards you at 4pm on a Friday.
The ESU price curve: 75, 150, 300
ESU pricing for SQL Server 2016 escalates hard: roughly 75% of the full license price in year one, 150% in year two, and 300% in year three. Add it up and staying put for the full window costs 525% of your license. That’s more than five licenses’ worth of money, for security patches only. No new features, no support tickets, no performance work. You’re paying rent on a building scheduled for demolition, at a rate that doubles each year.
The 75-150-300 ESU curve
The curve isn’t an accident, and it isn’t unique to SQL Server. Windows 10 ESUs follow the same doubling pattern: $61 per device in year one, $122 in year two, $244 in year three, running through October 2028. Microsoft prices ESUs to be survivable for exactly one budget cycle and punishing after that. The pricing is designed to push you off 2016, not keep you on it. Treat it as a bridge toll, never a destination.
Your four options at a glance
| Option | Best for | Cost shape | Pros | Cons |
|---|---|---|---|---|
| A: Buy ESUs | Apps retiring within ~12 months | 75% of license price, escalating to 300% | Zero migration work now; patches keep coming | Priciest way to stand still; security-only fixes; year-two math gets ugly |
| B: In-place upgrade to SQL Server 2022 | On-prem estates staying on-prem | New licenses plus regression-testing effort | Keeps infra and ops unchanged; compatibility levels soften the jump | License spend; a downtime window; app regression testing is the real work |
| C: Rehost to Azure (SQL MI or Azure VMs) | Workloads already headed to cloud | Azure consumption replaces license and ESU line items | ESUs come free on Azure; managed-instance ops relief | Recurring bill; networking and latency rework; not every feature maps 1:1 |
| D: Modernize to PostgreSQL | Shallow T-SQL apps; teams done with per-core licensing | One-time migration engineering; near-zero license line after | Ends the EOL treadmill instead of rescheduling it | Highest one-time effort; deep T-SQL/SSRS/CLR coupling turns it into a rewrite |
The four options compared
Real estates rarely pick one lane. The pattern we see: the core line-of-business database takes B or C, the reporting workload takes D, and the two apps already scheduled for retirement take a single deliberate year of A. Costing each workload separately is what makes the deadline manageable.
When paying for ESUs makes sense
In exactly one situation: the application is already dying. If a system gets replaced or retired within roughly a year, one year of ESU at 75% of license cost is cheaper and safer than migrating a corpse. Write the kill date down, budget the ESU as a line item with an end, and move on to the workloads that have a future.
What ESUs are not is a strategy. We’ve watched teams buy year one “for breathing room” and then discover that year two costs double and the migration project never got staffed. Procrastination is the default, not the exception. When Windows 10 hit end of support, 18% of partners’ customers had no defined migration path at all, and another 29% didn’t expect to upgrade until six months past the deadline or later. The ESU curve exists because Microsoft has seen those numbers too.
What an in-place upgrade to SQL Server 2022 involves
If your workloads are staying on-prem, the jump from 2016 to 2022 is the boring, correct answer, and boring is a compliment in databases. The mechanics: stand up 2022 alongside production, restore a copy, run it at 2016’s compatibility level first so query behavior matches what your apps expect, then step the level up once everything proves out. The install takes an afternoon.
The testing takes the weeks. Budget for regression passes across everything sitting on top of the database: linked servers, SQL Agent jobs, SSRS reports, ORMs pinned to old driver versions, and any T-SQL leaning on deprecated behavior. Rehearse the rollback before cutover, not during it. The teams that get burned are reliably the ones that rehearsed nothing. If the application layer itself is old enough to need work, our modernization cost guide covers the rewrite-vs-refactor math that usually comes up next.
How Azure gets you free security updates
Microsoft’s standing carrot in every end-of-support cycle: rehost the workload in Azure, either Azure SQL Managed Instance or SQL Server on Azure VMs, and extended security updates come at no extra charge while you finish modernizing. You’re trading the ESU line item for an Azure consumption bill, so it’s not free money. But if cloud was already on your roadmap, the deadline converts into a migration you wanted anyway, with the patch problem solved on day one.
Managed Instance buys the most ops relief (patching, backups, and high availability handled for you) at the cost of a few feature gaps you need to check against your estate. Cross-database dependencies and older integration patterns are the usual suspects. Sizing the bill is its own exercise; our cloud migration cost breakdown covers per-workload numbers, and our cloud consulting team runs these assessments every week.
When PostgreSQL is the right exit
When the database is a plain relational store and you’re done paying per-core licensing forever. Apps with a shallow T-SQL surface (CRUD through an ORM, few stored procedures, no SSRS, SSIS, or CLR) port to PostgreSQL well, and the license line drops to roughly zero and stays there. That’s the honest appeal of option D: it’s the only one that ends the end-of-life treadmill instead of rescheduling it for the next version’s retirement party.
The honest warning: heavy stored-procedure logic, SSIS pipelines, or CLR assemblies turn a “database swap” into an application rewrite. If that’s your estate, don’t attempt D under deadline pressure. Do B or C now and revisit Postgres with room to breathe. Modernization is a $21.9 to 30B market in 2026 heading toward roughly $92B by 2034 precisely because these projects reward planning and punish panic.
The compliance exposure under PCI and HIPAA
Neither PCI DSS nor HIPAA names database versions. What they require is supported software with a working patch process, and an end-of-support engine fails that test by definition, which is why assessors treat EOL databases as findings rather than judgment calls. The same exposure was the headline risk when MySQL 8.0 hit end of life on April 30, 2026: analysts flagged audit failure under PCI DSS and HIPAA as the primary risk, ahead of breach probability itself. The logic transfers to SQL Server one-to-one.
And 2026 is a pile-up year for exactly this conversation. MySQL 8.0 is already past EOL, SQL Server 2016 goes in July, and .NET 8 and .NET 9 both end support on November 10, 2026. If you’re opening a modernization window anyway, sweep the stragglers into one planning cycle. We wrote up the .NET upgrade plan separately.
The 60-day plan, week by week
For a single, reasonably understood database: yes, and with margin. For a 40-instance estate: no, and anyone promising otherwise is selling something. Estates get triaged instead. Regulated and internet-facing workloads move first, internal tools follow, and the long tail gets one priced year of ESU as a bridge with a written end date.
| Weeks | Phase | What gets done |
|---|---|---|
| 1 to 2 | Inventory and baseline | Map instances, databases, app dependencies, drivers, agent jobs; capture performance baselines; flag compliance-scoped data |
| 3 to 4 | Pick the lane, build the target | Choose A/B/C/D per workload; stand up SQL Server 2022 or the Azure target; restore production copies |
| 5 to 6 | Trial migration and regression | Migrate a copy; run app regression and performance comparisons against baseline; fix drivers, jobs, and broken T-SQL |
| 7 | Cutover rehearsal | Timed dry run including rollback; sign-offs from application owners; freeze change windows |
| 8 | Production cutover and hypercare | Cut over in the agreed window; monitor for a week against baseline; decommission or quarantine the 2016 boxes |
The 60-day plan, week by week
The plan’s quiet advantage isn’t speed. Weeks 1 and 2 produce the dependency inventory most teams have never actually had, and once that exists, the rest is sequencing rather than discovery.
How gmware runs one of these migrations
We run these as fixed-scope engagements for single databases and T&M for estates. An Austin-side architect owns the cutover plan, and engineers in Bangalore and Mohali build the migration runbooks, run the regression passes, and grind through the parallel-run comparisons, with enough US-hours overlap that your cutover rehearsals happen while your team is awake. We’re opinionated about lane choice, and sometimes the opinion is unprofitable for us: if your app retires next year, we’ll tell you to buy the ESU year and bank the difference.
What we won’t do is quote a migration off a phone call. The inventory comes first, because that’s where every surprise lives: the linked server nobody documented, the SSRS report payroll quietly depends on.
Five weeks is enough time to pick a lane and start moving. Tell us what you’re running, instance counts, rough sizes, compliance scope, and we’ll come back within 48 hours with a straight recommendation on which option fits which workload, what it’ll cost, and whether your timeline is real.