Every SQL Server deadline buys the same thing: a project that delivers nothing new. There is a version of that project you only ever run once.
Key takeaways
- The standstill project – Much of what passes for modernisation is a project that delivers nothing new: months of testing and real budget spent so that everything works exactly as it did before.
- A sequence, not an event – SQL Server 2016 fell out of support in July. Windows Server 2016 follows in January 2027, SQL Server 2017 in October – and 2019 and 2022 are already queued behind them.
- Standing still is now priced – Extended Security Updates cost roughly a full licence fee per year, in every environment including Azure. The free exits Microsoft used to offer are gone.
- There is a version of this project you run once – Azure SQL’s managed tiers carry no end-of-support date. Move a workload there properly and it never joins the queue again.
Somewhere in your estate, a team is scoping an SQL Server 2016 project whose definition of success is that nobody notices anything. The applications must behave exactly as they did. The reports must reconcile to the cent. Months of discovery, regression testing and vendor certification – budgeted, staffed and signed off – to arrive precisely where you already are. I have watched South African enterprises run that project for every version since 2008, and its honest description rarely appears on the business case.
We call it the standstill project: the recurring programme of work an organisation funds purely to keep what it already has. It is the tax the version life cycle collects every few years – and July’s end of support for SQL Server 2016 has just issued the next invoice.
A sequence, not an event
The estates treating 14 July as an isolated fire are misreading it. Windows Server 2016 – the operating system under many of those same database servers – reaches end of support on 12 January 2027, drawing on the same change windows, the same teams and the same testing capacity. SQL Server 2017 follows on 12 October 2027. SQL Server 2019 and 2022 are already dated behind them, in 2030 and 2033.
Each deadline re-runs the standstill project in full: the same estate discovery, the same regression cycles, the same cutover risk, the same quarter of consumed delivery capacity. Nothing new ships. The organisation pays in scarce engineering attention for the privilege of remaining where it is.
The deadline is not the problem. The queue is.
Standing still now has a price list
For a decade, there was a quiet escape from that queue: move the workload onto an Azure virtual machine and Microsoft supplied Extended Security Updates at no charge. That arrangement ended with this cycle. SQL Server 2016 ESUs are chargeable in every environment, including Azure, at roughly the full licence cost per year – and enrolment after an ESU year begins is back-billed to the start of that year, so hesitation saves nothing.
The bridge also has a hard end. Coverage runs to July 2029 and no further; a 2016 estate still standing then has no supported option at any price. Three years of full licence fees, buying no capability, ending at a wall – that is not a plan. It is a countdown with invoicing attached.
The strategic read matters more than the numbers. Microsoft has repriced inaction. Deferral used to be a default that cost nothing; it is now a metered product with a published rate. Any organisation still on 2016 is making a priced decision, whether or not it has recognised the price.
The honest case for upgrading in place
An upgrade to SQL Server 2025 is a legitimate answer, and we will say so plainly. Vendor applications not yet certified for cloud, workloads bound by data-sovereignty commitments, latency-critical systems, recently refreshed hardware – these are real constraints, and for estates governed by them, an in-place upgrade to a current, supported, capable platform is the disciplined move.
Be clear about what it buys. SQL Server 2025 carries its own support clock, and the standstill project returns on schedule when that clock runs down. An in-place upgrade is a better version of the same transaction: this decade’s features, and the next decade’s deadline. Sometimes that is exactly the right purchase – but it should be made knowingly, not by default.
The project you only run once
Azure SQL Managed Instance and Azure SQL Database are versionless. There is no release to fall behind, no extended support date to diarise, no ESU programme to price. The platform is patched and kept current continuously, under an engine that preserves near-complete compatibility with on-premises SQL Server, while Azure Hybrid Benefit carries your existing licence investment across.
A workload migrated there properly has left the queue permanently. The 2016 project, the 2017 project, the 2019 and 2022 projects that estate was destined to fund – that entire category of work disappears for the workloads that make the move. Not every workload can: some genuinely need the control of SQL Server on an Azure virtual machine, and those remain on the version life cycle. Knowing which is which is precisely the work that makes the exit real.
The question is not whether you can afford the migration. It is how many more standstill projects you intend to fund.
The project you only run once
Ascent’s Migrate your SQL Server to Azure service is built assessment-first, because the assessment is what makes the exit permanent rather than cosmetic: it establishes which workloads can take the versionless tiers, which need the control of a virtual machine, and in what sequence the estate should move.
Delivery then runs as a governed migration under the Modernise–Optimise–Protect framework – performance baselined before cutover, cost engineered through Azure Hybrid Benefit and right-sizing rather than discovered on the first invoice, security and compliance controls carried across by design.
Because Ascent is a Microsoft Direct CSP, the commercial layer can sit under the same accountability as the delivery: licensing, Azure consumption and, where a short bridge is genuinely unavoidable, the ESU licensing itself.
One partner accountable for the migration and for the commercial ground it stands on – that is what turns Migrate your SQL Server to Azure from a project into the end of a cycle.
The 2016 deadline has already passed, and the next two are dated. The choice in front of a 2016 estate is between running the last standstill project deliberately – once, properly, to a destination without deadlines – or funding the next one by default.
The question is not whether you can afford the migration. It is how many more standstill projects you intend to fund.
Share
Editorial contacts