Two significant Microsoft deadlines frame the end of 2026 for many IT teams. Extended Support for SQL Server 2016 ended on July 14, 2026, and Extended Support for Windows Server 2016 ends on January 12, 2027, according to Microsoft’s Extended Security Updates pages. Windows Server 2016 was a popular release, and SQL Server 2016 underpins countless line-of-business applications, so these dates affect a large share of enterprise estates.
End-of-support deadlines are often treated as an annoyance to be handled with the minimum possible effort. They can also be a useful forcing function: a moment to decide, application by application, whether to upgrade in place, migrate to the cloud, modernize onto platform services or buy time with extended security updates. This guide walks through the options, the decision criteria and a practical plan for the months around the deadline.
What End of Support Actually Means
When a product leaves Extended Support, Microsoft stops providing regular security updates, non-security fixes and assisted support for it, except for customers who purchase Extended Security Updates (ESUs). Systems do not stop working, which is precisely why the risk is easy to underestimate. Unpatched servers become progressively more exposed as new vulnerabilities are disclosed, and many regulatory and contractual frameworks, as well as cyber insurance policies, expect organizations to run supported software or have compensating controls.
Microsoft’s Extended Security Updates page lists the key dates around this period:
- July 14, 2026: SQL Server 2016 Extended Support ends and its ESUs begin.
- October 13, 2026: Windows Server 2012 ESUs end.
- January 12, 2027: Windows Server 2016 Extended Support ends and its ESUs begin.
- July 12, 2027: SQL Server 2014 ESUs end.
That clustering matters. Many estates still contain Windows Server 2012 and SQL Server 2014 alongside the 2016 versions, so a single program can address several deadlines at once.
An end-of-support date is not just a patching deadline. It is the cheapest moment you will get to decide, application by application, where each workload should live for the next five years.
Your Five Options
For each affected server or database, there are essentially five paths. Most estates will use several of them.
1. Upgrade in place or side by side
Move to a supported version, such as Windows Server 2025 or SQL Server 2025, which Microsoft lists as upgrade options, on existing infrastructure. Side-by-side upgrades, building new servers and migrating applications and data, are usually safer than in-place upgrades and give you a clean rollback path. This option suits applications that must stay on premises and are compatible with newer versions.
2. Rehost to the cloud with an upgrade
Migrate the workload to cloud virtual machines and upgrade the operating system or database version as part of the move. Microsoft notes that Azure Migrate can upgrade the operating system during migration. Combining the move and the upgrade avoids doing two projects, but it also combines two sources of risk, so testing must be thorough.
3. Modernize onto platform services
Move databases to a managed service, such as Azure SQL Managed Instance or Amazon RDS for SQL Server, and web applications to a platform service such as Azure App Service. Microsoft lists App Service and SQL Managed Instance as ways to move off end-of-support versions entirely. Managed platforms shift patching and version management to the provider, which reduces the chance of facing the same deadline again in a few years.
4. Buy time with Extended Security Updates
ESUs provide security updates for a limited period after Extended Support ends. Microsoft describes three routes:
- In Azure: ESUs for Windows Server and SQL Server for three more years when workloads run on Azure Virtual Machines, Azure Dedicated Host, Azure VMware Solution or the Azure Stack portfolio, with Azure Hybrid Benefit available to reduce costs.
- Through Azure Arc: for on-premises or hosted servers, ESUs can be purchased and deployed through Azure Arc on a pay-as-you-go subscription model, managed from the Azure portal. Microsoft states that Arc-enabled ESUs require Software Assurance under an Enterprise Agreement.
- Through Volume Licensing: classic ESUs bought in yearly increments.
ESUs are a bridge, not a destination. They cover security updates but do not add features or restore full support, and costs generally make them unattractive as a long-term strategy. Check current pricing and terms with Microsoft or your licensing partner, because they vary by route and agreement.
5. Retire, replace or isolate
Some workloads should not be upgraded at all. Applications that are rarely used, duplicated elsewhere or due for replacement by a SaaS product can be retired or replaced. For the few systems that cannot be changed, such as equipment control software certified only on an old version, isolation and compensating controls may be the only realistic option. For applications that cannot run on newer Windows versions, AWS has offered an End-of-Support Migration Program for Windows Server since 2019, which packages legacy applications with a compatibility layer so they can run on supported Windows versions on Amazon EC2; AWS itself advises using it only when upgrading is not possible. Confirm current availability and terms before relying on it.
Decision Criteria
Choosing among these options requires a short, consistent assessment of each application. The following criteria cover most decisions.
- Business value and lifespan: how important is the application, and how long will it be needed? Applications with less than two years of remaining life may be candidates for ESUs or retirement rather than investment.
- Compatibility: does the vendor support the application on newer Windows Server or SQL Server versions? Check vendor support matrices early, because this is often the longest lead-time item.
- Placement: should the workload remain on premises for latency, data residency or integration reasons, or is the cloud a better home?
- Modernization appetite: is there budget and skill to move to managed services now, or is a like-for-like move more realistic before the deadline?
- Licensing position: do you have Software Assurance, existing cloud commitments or licenses that can be reused through programs such as Azure Hybrid Benefit?
- Risk and compliance: what do regulators, auditors, customers and insurers require regarding supported software?
- Timing: can the work realistically be completed before the deadline, or is a short ESU bridge needed to avoid a rushed migration?
Comparing the Options Side by Side
A quick comparison helps when presenting options to leadership. The trade-offs typically look like this:
- Upgrade on premises: lowest disruption to architecture and operations, but you keep the hardware, facilities and patching burden, and you will face the next deadline on the same terms.
- Rehost to cloud with upgrade: moves the workload off aging infrastructure and can be done relatively quickly with mature tooling, but delivers limited operational simplification unless followed by optimization.
- Modernize to platform services: highest long-term benefit, because the provider handles patching and version upgrades, but requires more testing and sometimes application changes, so it is harder to finish before a near-term deadline.
- Extended Security Updates: fastest way to stay protected, but adds recurring cost and only defers the decision.
- Retire or replace: eliminates the problem entirely for the application in question, but depends on business agreement and, for replacements, on procurement timelines.
In practice, a mixed approach is almost always right: modernize where the application is strategic and compatible, rehost or upgrade where speed matters, retire where value is low and use ESUs narrowly for the exceptions that genuinely cannot meet the deadline.
A Practical Plan for the Deadline Window
With SQL Server 2016 already past its deadline and Windows Server 2016 only weeks away, many organizations are working against the clock. The following sequence helps.
Weeks 1–2: Inventory and triage
Build a complete inventory of affected servers and database instances, including those hidden inside appliances, development environments and disaster recovery sites. Discovery tools, configuration management databases and cloud provider assessment tools help, but validate the results with application owners. Tag each item with business owner, criticality, dependencies and current support status of the application itself.
Weeks 2–4: Decide per application
Apply the decision criteria and assign each application one of the five paths. Group applications that share databases or dependencies so they move together. Identify which workloads cannot be finished before the deadline and decide whether to cover them with ESUs, and through which route.
Weeks 4 onward: Execute in waves
Run the upgrades, migrations and modernizations in small, sequenced waves, starting with lower-risk systems to refine the process. Test application compatibility carefully, especially for database compatibility levels, deprecated features, drivers and authentication methods. Keep rollback options open until each workload has been validated by its users.
In parallel: Harden what remains
For any server that will run past its support date, whether covered by ESUs or not, strengthen compensating controls: network segmentation, restricted administrative access, enhanced monitoring and endpoint protection. Document these controls for auditors and insurers.
Common Technical Gotchas
- Database compatibility levels: moving to a newer SQL Server version or a managed service can change query behavior. Test performance-critical queries and consider initially keeping the older compatibility level, then raising it deliberately.
- Deprecated features: older features and integrations may have been removed or changed in newer versions. Review the documentation for discontinued features before upgrading.
- Drivers and connection strings: client applications may need updated drivers, especially when moving to managed services with stricter encryption defaults.
- Authentication and identity: moving to cloud services often requires changes to how applications authenticate, such as adopting managed identities or directory-integrated authentication.
- Hidden dependencies: scheduled tasks, linked servers, file shares and SQL Server Agent jobs frequently surface late. Inventory them explicitly.
- Third-party agents: backup, monitoring and security agents must support the new operating system or platform.
A Hypothetical Example
Consider a hypothetical regional healthcare provider with about 120 Windows Server 2016 virtual machines and 25 SQL Server 2016 instances in its own data center, plus a handful of Windows Server 2012 machines already covered by ESUs that expire in October 2026.
A two-week inventory confirms the scope and reveals that eight applications are from vendors who do not yet support newer versions. The triage assigns paths: about a third of the servers host internal web applications that move to a platform service; most SQL Server 2016 databases move to a managed database service after compatibility testing; a group of servers supporting clinical systems that must remain on premises are upgraded side by side to Windows Server 2025; several rarely used applications are retired; and the eight vendor-constrained applications are covered by ESUs through Azure Arc for one year while the provider works with the vendors on upgrades or replacements.
The Windows Server 2012 machines, whose ESUs expire first, are prioritized in the first wave. Compensating controls are documented for every server that will temporarily run on ESUs. By the January 2027 deadline, most of the estate is on supported platforms, and the remaining exceptions have a clear plan, an owner and an end date.
Pitfalls to Avoid
- Treating ESUs as a strategy. They buy time; they do not solve the underlying problem.
- Forgetting non-production and disaster recovery environments. They are part of the attack surface too.
- Discovering vendor constraints late. Engage software vendors in the first weeks.
- Upgrading without a rollback plan. Side-by-side approaches are slower but safer.
- Missing the chance to modernize. Moving to managed services now can prevent the same scramble at the next deadline.
- Ignoring licensing. Licensing choices can change the economics of each option significantly.
Looking Ahead
The Windows Server 2016 and SQL Server 2016 deadlines will not be the last. Every version of an operating system or database eventually reaches the same point, and organizations that run large estates of self-managed servers face these deadlines every few years. Using this deadline to move appropriate workloads to managed platforms, to standardize on infrastructure as code and automated patching, and to maintain an accurate inventory with support dates will make the next deadline far less disruptive. A simple practice helps: add support end dates to your configuration database and review them quarterly, so that the next migration starts two years before the deadline rather than two months.
Conclusion
With SQL Server 2016 already past its Extended Support date and Windows Server 2016 reaching it on January 12, 2027, the time for planning is short. Inventory every affected system, decide per application among upgrading, migrating, modernizing, buying time with ESUs or retiring, and execute in small waves while hardening anything that will run past the deadline. Treat ESUs as a bridge to a defined destination. Approached this way, the deadline becomes an opportunity to reduce risk, simplify operations and modernize the estate rather than just another emergency patch cycle.
How Hanoi Technology Can Help
Hanoi Technology helps organizations inventory end-of-support systems, choose the right path for each application and run upgrades, migrations and modernizations in safe waves, through projects, dedicated teams or managed services.