Many enterprises, especially in South Africa, are facing modernization projects that are essentially 'stagnation projects'—they require months of testing and significant budget expenditure just to ensure systems function exactly as before, without any new enhancements.
SQL Server 2016 ended support in July. However, this is only the beginning of a sequence of events: Windows Server 2016 will stop being supported in January 2027, and SQL Server 2017 in October 2027. Following these are versions 2019 and 2022, scheduled for 2030 and 2033, respectively.
Maintaining the current state now comes at a cost. Extended Security Updates (ESU) cost approximately the full license fee annually across all environments, including Azure. The free options previously offered by Microsoft are no longer available.
A Sequence, Not an Isolated Incident
Enterprises viewing July as an isolated crisis are mistaken. The Windows Server 2016 operating system, which underpins many database servers, will reach end-of-support on January 12, 2027. This will necessitate using the same change windows, commands, and testing capacity as previous cycles. SQL Server 2017 will follow on October 12, 2027, with versions 2019 and 2022 slated for 2030 and 2033.
Each new support deadline triggers a full cycle of a 'stagnation project': infrastructure rediscovery, regression testing cycles, migration risk, and resource consumption. The organization pays a premium of scarce engineering attention simply to remain at the same level. The problem is not the deadlines, but the update queue itself.
Status Quo Now Comes With a Price Tag
For ten years, there was a quiet way out of this queue: moving the workload to an Azure virtual machine while Microsoft provided ESU for free. That arrangement has ended. Now, ESU for SQL Server 2016 is paid for in all environments, including Azure, at approximately the full license cost per year. Furthermore, if registration begins after the start of the ESU year, payment will be retroactive, so procrastination will not help.
This temporary bridge also has a hard limit: coverage is only valid until July 2029. An enterprise still using version 2016 by then will find no supported option, regardless of the price. Three years of paying the full license without gaining new capabilities is not a plan; it is a countdown with invoices. Microsoft has revised the cost of inaction: what was once a free option is now a tiered product.
A Fair Argument for In-Place Upgrade
Upgrading to SQL Server 2025 is a justified decision. There are real constraints, such as vendor applications not yet certified for the cloud, systems bound by data sovereignty obligations, or latency-critical systems, as well as recently updated hardware. For such environments, a disciplined step is upgrading to the current, supported, and functional platform.
It is important to clearly understand what such an upgrade provides. SQL Server 2025 has its own support schedule, and the 'stagnation project' will return on schedule when that schedule expires. An in-place upgrade is an enhanced version of the same transaction: the capabilities of this decade and the support period of the next decade. Sometimes this is precisely the right purchase, but it must be conscious, not automatic.
The Project That Gets Done Once
Azure SQL Managed Instance and Azure SQL Database are serverless (versionless). They do not have releases, lag, extended support dates, or ESU programs to pay for. The platform is continuously updated and maintained on an engine that retains near-full compatibility with on-premises SQL Server, while Azure Hybrid Benefit allows leveraging existing license investments. Workloads correctly migrated there permanently exit the queue. The entire spectrum of work related to the 2016, 2017, 2019, and 2022 projects disappears for these workloads.
Not every workload can be migrated; some genuinely require SQL Server control on an Azure virtual machine, and they remain in the version cycle. Accurately defining what fits is the key to truly exiting the cycle. The question is not whether you can afford the migration, but how many more stagnation projects you intend to fund.
How Ascent Works
The Ascent service, 'Migrate your SQL Server to Azure,' is built on a preliminary assessment because the assessment is what makes the exit permanent, not superficial. It determines which workloads can move to serverless tiers, which require VM control, and in what sequence the infrastructure migration should occur.
Implementation proceeds as managed migration within the Modernise–Optimise–Protect framework. A baseline performance measurement is taken before the switch, costs are calculated using Azure Hybrid Benefit and size optimization, and security and compliance elements are implemented from the outset. Since Ascent is a direct Microsoft CSP, the commercial layer can be under the same responsibility as the implementation: licensing, Azure consumption, and ESU licensing if a short transition period is needed.
Having one partner responsible for both the migration and the commercial foundation turns 'Migrate your SQL Server to Azure' from a project into a cycle completion. The 2016 support window has passed, and the next two windows are scheduled. The choice for the 2016 infrastructure is whether to intentionally undertake one last stagnation project—once, correctly, to a destination without deadlines—or to fund the next one by default.