For most of the last decade, Microsoft made it inexpensive to wait. Each time a SQL Server version reached the end of its extended support – 2008, 2012, 2014 – the same escape hatch was available. Move the workload onto an Azure virtual machine and the Extended Security Updates came free. SQL Server 2014 still carries that arrangement, running to July 2027.

SQL Server 2016 does not. Since 15 July, ESU coverage for its production workloads has been chargeable on Azure exactly as it is anywhere else, with narrow exceptions for non-production instances and passive replicas.

Key takeaways

The subsidy on waiting has been withdrawn – for three end-of-support cycles Microsoft made deferral effectively free on Azure, and with SQL Server 2016 it stopped. That is the material change in this cycle, not the deadline itself.
Delay is now a priced, cumulative and back-billed decision – Microsoft’s SQL Server guidance puts Extended Security Updates at approximately 75% of licence cost a year, on a term running to July 2029, and late enrolment bills back to its first day. Waiting defers the invoice without reducing it.
This is a schedule, not an event – Windows Server 2016 follows in January 2027 and SQL Server 2017 in October 2027. An organisation planning around one date is planning around a third of the problem.
Under Popia, unsupported becomes difficult to defend as reasonable – the Information Regulator has already found a section 19 contravention on lapsed security tooling, and a South African cyber insurer asks applicants to sign that they run nothing the vendor no longer supports. That moves the decision off the IT roadmap and onto the risk register.
The choice on the table is larger than which version comes next – one of the available destinations has no engine-version deadline to plan around and no ESU to buy. The others buy a runway and re-enter the cycle.

A version reaching the end of its life is routine. The quiet withdrawal of the subsidy that made deferral affordable is not, and it is the part of this cycle worth attention. Delay used to be free. It is now priced. And the meter does not stop.

The deal that expired

The free-ESU-on-Azure route was never charity. It was a commercial instrument, and an effective one – Microsoft used it for three consecutive cycles to convert end-of-support pressure into Azure consumption, and a great many South African estates moved on exactly that logic. The workload did not modernise. It relocated, and the security updates arrived with the postage paid.

Two ESU programmes are running side by side right now, under opposite rules. SQL Server 2014 keeps free updates on an Azure VM until July 2027. SQL Server 2016 entered a paid ESU term on 15 July 2026.

Until next July, one organisation collects its patches free while the one next door pays close to licence price again for the same programme, from the same vendor, in the same month.

The detail that catches organisations is the back-billing. Enrolment after the term has started is charged back to the first day of that term, so a company that spends six months deciding does not save six months of cost – it receives the same invoice later. Coverage runs three years, to 17 July 2029, licensed against the virtual cores assigned to each machine subject to a four-core minimum, or through a physical-core model where the host configuration justifies it.

Microsoft is candid about what this costs. Its SQL Server end-of-support guidance puts ESUs at approximately 75% of the on-premises licence cost annually, and calls the option, in its own words, costly.

Read that across the full term. Two and a quarter times what the licences cost, spent entirely on remaining where you are. The rate does not need to escalate to do damage. It simply runs every year, against every core, until the workload moves.

The published percentage is still not an organisation’s own number. What it pays turns on edition, core count, licensing programme, channel and commercial terms, which is why Microsoft routes the question to an account team or a licensing partner. The rate is published. The bill is not, until somebody asks for it.

For a decade the finance case for postponement was strong, because postponement was subsidised. It is not any more, and in my experience a good many organisations have not yet put the new number in front of the people who would have to approve it.

One date, three deadlines

Most of the planning I see is built around a single deadline. There are three.

Windows Server 2016 – the operating system underneath a large share of these database estates – reaches end of support on 12 January 2027. SQL Server 2017 follows on 12 October 2027. A company that solves only its SQL Server 2016 problem will be back at the same table twice more inside 18 months, each time with less room to plan and more of the budget already spent.

This is the structural point, and it is the one most easily missed. End-of-support dates do not arrive as events. They arrive as a schedule, published years ahead, entirely predictable. Responding to them one at a time, reactively, at whatever price the vendor sets on the day, is the most expensive available way to manage a calendar you were given in advance.

A bridge, not a destination

Microsoft is explicit that Extended Security Updates are a bridge for workloads that cannot move yet – application dependencies, testing constraints, genuine migration complexity. That framing is honest and it is correct. The programme exists so that a regulated estate is not forced into an unsafe migration by a date on a lifecycle page.

What it is not is a strategy, and the arithmetic makes that plain. Three years of coverage buys the right to remain exactly where you are. At the end of it, the same decision is waiting – except the migration budget has been spent on not migrating, and the estate is three years older.

There is also a limit to what the bridge carries. Microsoft issues SQL Server ESUs only for vulnerabilities its Security Response Centre rates Critical, and says plainly that there is no regular release cadence for them. An estate on ESUs is not a supported estate that happens to be paying more. It is an unsupported estate receiving a subset of the fixes, on no schedule.

There is a version of this that is defensible: a costed, time-boxed bridge with a migration programme already funded and running beneath it. There is a version that is not: an ESU subscription renewed each year because the alternative keeps getting deferred. The two look identical on the invoice. They look nothing alike three years later.

Reasonable measures

For South African organisations there is a second cost that never appears on the licensing quote.

Popia requires appropriate, reasonable technical and organisational measures to secure personal information. That standard is not defined by a checklist, which is precisely why it is difficult to argue with.

Once a vendor has publicly ended security support for a product, running it in production against personal information becomes a position that has to be actively defended – by ESU coverage, by isolation, by controls that demonstrably work. Defended by nothing at all, it is a hard position to hold in front of a regulator after an incident. The evidence of what was known, and when, is published on Microsoft’s own website.

The Information Regulator has already run a version of this argument. Its 2023 enforcement notice against the department of justice found section 19 contraventions grounded in expired security-software licences – monitoring, intrusion detection and antivirus, all lapsed since 2020, leaving virus definitions unupdated when the ransomware arrived. When the department missed the deadline the notice set for renewing them, the Regulator fined it R5-million.

Lapsed licences are not an unsupported version, but the reasoning transfers: security tooling that cannot be kept current is, on the Regulator’s own analysis, a section 19 problem. Popia binds a private company on the same terms it bound the department.

Insurers reached the same place some time ago. On one South African commercial cyber form, running software the vendor no longer supports is not a question at the end of a checklist. It sits among the minimum security requirements the applicant signs to confirm, alongside applying security patches within three months of release, and the form is expressly made the basis of the contract. UK and Australian forms ask it outright.

Leaving the cycle

An answer given carelessly there is not a paperwork problem. It is a coverage problem, discovered at the worst possible moment.

Which means the decision has quietly changed hands. An end-of-support date used to be an IT roadmap item, argued for in a capital budget round. A question that determines regulatory defensibility and the strength of an insurance claim belongs on the risk register, and it belongs in front of the people who sign for both. In most organisations I see, it is still being decided three levels below that.

There is one more thing about this cycle that deserves saying plainly.

The Azure SQL database engine is evergreen. Microsoft calls Managed Instance versionless under its always-up-to-date policy: no engine-version end-of-support date to plan around, no ESU programme to buy. The caveat is real, though. A new managed instance defaults to a policy pinned to SQL Server 2022, running to that version’s mainstream end in January 2028 before rolling forward on its own, and features and APIs still retire on published dates. What disappears is the migration project, not every deadline.

Upgrading in place to SQL Server 2025 is a sound and often correct decision – it buys a long, well-defined runway. But it is a runway, and at the end of it the organisation is standing in this same conversation again.

So, the choice on the table is larger than which version comes next. It is whether the business wants a recurring, capital-consuming deadline cycle on its books for the next 20 years, or whether this is the moment to step out of it.

That is not a free choice, and I would not present it as one. Versionless platforms move the cost from periodic capital events to a continuous operating line, which suits some balance sheets and unsettles others. Some workloads genuinely cannot move – licensing entanglements, application certification, latency, data residency positions that have not yet been worked through. The honest answer for many estates is a mixed one, sequenced over several years.

But it is a decision that should be made once, deliberately, with the 20-year shape of it understood. Not one that gets remade by default at the end of each product lifecycle, because another support date arrived and something had to be done about it.

The last word

I have now watched three of these cycles from close range, and what strikes me is how consistently the deferral decision gets made on the last cycle’s terms. The assumption that moving to Azure keeps the security updates free was true for a decade.

It was true right up until the middle of last month.

Across 20 years of Ascent’s work in South African data estates, that is the pattern I would expect to repeat. A good number of organisations will discover this change on an invoice rather than in a planning session.

Windows Server 2016 reaches its own end of support in January. By then, every organisation still running a 2016-era estate will have answered this question, whether or not they sat down to answer it. Some will have decided. Most will have let the date decide.