Extended Security Updates run at roughly 75% of the license price per year, and they cover security patches, nothing else. Worth calculating before the next renewal gets signed..
SQL Server 2016 reached the end of extended support in July 2026. SQL Server 2014 ran out in July 2024, SQL Server 2012 in July 2022. Between them, those three releases still run a good share of the production databases in European enterprises.
Nothing broke. Databases kept running, applications kept working, nobody was locked out. That is what makes the decision so easy to put off: the date itself produces no incident and no alarm in anyone’s dashboard. What changes is slower and harder to see. The risk profile shifts, the cost profile shifts, and the decision moves quietly out of the architecture team and into the procurement calendar.
What End of Support Changes
After the date, Microsoft stops shipping security updates, bug fixes and technical support for the version. The software itself carries on. It is simply no longer maintained, and that matters far less on day one than it does eighteen months later, when a critical vulnerability is published and there is no patch to install.
The usual response to a passed deadline is to buy Extended Security Updates, and on paper it looks like the careful choice. No migration project. No application testing. No risk. However, it buys less than most budget holders assume.
ESUs cover critical security fixes and nothing else: no functional fixes, no new features, no performance improvements, and no relief for the team that keeps the estate running. The program lasts three years at most, after which the same decision comes back around with less runway than the first time.
Then there is the price. Microsoft’s published guideline is roughly 75% of the on-premises license price per year, though what any individual customer pays depends on edition, core count, licensing program and channel, and billing applies a four-core minimum per machine. Over a full ESU term that adds up to something close to the value of the licenses themselves, spent entirely on security patches.
Delivery is the other thing worth knowing about. For on-premises instances the documented route runs through Azure Arc, so the estate ends up connected to Azure anyway, which is often the step the organization was trying to avoid in the first place. Instances that stay disconnected can be licensed through volume licensing and registered by hand, at the cost of more administration.
One detail catches people out. SQL Server 2014 instances moved to Azure VMs get their ESUs for free. From SQL Server 2016 onward that subsidy is gone: ESUs require a paid subscription even on an Azure VM. The escape route that worked last time around is closed.
Azure SQL Database and Managed Instance sit outside all of this. They need no ESUs and carry no end-of-support date at all, which is the part that tends to get left out of the comparison. Moving to PaaS does not just answer this deadline. It ends the cycle.
What Agentic AI Needs From a Database
Agentic workloads do not run on an architecture diagram. They run on the operational databases that hold the data, which means the SQL estate ends up in the critical path of projects that were never discussed with the DBA team.
Older SQL releases were never designed for that. There is no native vector data type and no vector index before SQL Server 2025, and no Microsoft Entra ID sign-in for on-premises instances before SQL Server 2022. AI projects do not fail over this. They work around it. A second vector store gets procured, a copy of the data gets loaded into it, and someone builds a synchronization path between the two and then owns it for the next five years.
That workaround almost never appears in the AI project’s business case. It turns up afterwards, as a second platform to secure, a second copy of regulated data to govern, and an integration nobody planned to maintain. It is a cost of the legacy estate, charged to a different department.
What It Looks Like When Someone Does the Math
A global chemicals company we worked with had already done the difficult part. Every SQL Server had been moved out of the company’s own data centers and onto Azure in a lift-and-shift migration. The workloads were in the cloud, the data center exit was on schedule, and on an architecture diagram the project looked complete.
The IT team’s calendar told a different story. They were still provisioning instances, applying patches, sizing storage and handling availability, the same work as before, now in a different location. The migration had changed where the databases ran. It had changed nothing about who ran them.
We started with the numbers rather than with a target architecture.
Three things had to be established before anything moved.
- What the estate really cost. Not only infrastructure and licenses, but the internal staff cost of running SQL on IaaS: the hours going into provisioning, patching and day-to-day operations, priced like any other line item in the comparison.
- What each business unit actually needed. Performance and SLA requirements were benchmarked per unit instead of assumed. Several workloads turned out to be running on considerably more capacity than anyone had asked for. A couple needed more.
- What each target would cost. Every workload was costed against its realistic destination, whether that was Azure SQL Database, Managed Instance or staying on an Azure VM, with the cost of changing nothing included as a baseline.
The migration path was defined after that, and executed against it. Moving the SQL databases from IaaS to SQL PaaS on Azure brought the cost down by nearly 50%, a seven-figure saving for the company.
Four Things From That Project That Transfer
Lift and shift is a waypoint. Moving a database onto a cloud VM relocates the cost. The operational load stays exactly where it was. If your team still patches databases by hand, the migration is not finished.
Nobody prices the staff cost. Infrastructure and license spend sits in a report that somebody owns. The hours your DBAs spend on platform maintenance usually sit in no report at all, and in several of our assessments they turned out to be the largest single item in the comparison.
Not every workload belongs on PaaS. An honest assessment ends with a split. Some databases move to Azure SQL Database, some to Managed Instance, some stay on a VM because the numbers say so, and some applications need remediation before they can move anywhere. A plan that puts everything on PaaS has been assumed, not calculated.
The deadline is the budget. Money earmarked for ESUs, for an unchanged license renewal, or for another year of self-managed operations is the money that pays for the modernization. That comparison is arithmetic, and it can be done in a few weeks.
Where to Start
If SQL Server 2012, 2014 or 2016 is still in production, or a license renewal is sitting on someone’s desk, the first useful step is not choosing a target architecture. It is finding out what the estate costs today, what each workload would cost on each realistic target, and what doing nothing costs over the same period.
Everything after that becomes a scheduling question.
MobiLab helps organizations modernize their SQL estates on Azure, from the initial assessment and business case through to the full migration, benchmarked against what the business case promised.