Windows Server 2016 and SQL Server 2016 end of support
We upgrade or migrate Windows Server 2016 and SQL Server 2016 estates, before and after end of support. We inventory every instance, check what applications and vendors support on newer versions, and choose per server: in-place upgrade, rebuild, a move to Azure SQL or Azure VMs, or Extended Security Updates as a short bridge. Databases get upgraded with tested compatibility levels and a rollback point.
- 01Instance and licence inventory
- 02Path per server
- 03Database compatibility testing
- 04Application and vendor sign-off
- 05Cut-over and ESU clean-up
The story
Told without the client's name or anything that could identify them.
A distributor's infrastructure team found SQL Server 2016 instances flagged as unsupported by vulnerability scans after extended support ended on 14 July 2026, with Windows Server 2016 due to follow on 12 January 2027. A vendor application was certified only on 2016, and nobody could say which instances ran Standard or Enterprise or which cores had Software Assurance. We connected servers to Azure Arc to build the instance and licence inventory, then chose a path for each server: in-place upgrade, rebuild, Azure SQL Managed Instance, retire, or ESU as a dated bridge. Production backups were restored onto the target SQL Server versions and run at the old compatibility level, with Query Store watching for regressions, before the level was raised. Each cut-over had a rollback point, and ESU subscriptions were cancelled as servers left 2016.
why it was urgentSQL Server 2016 extended support ended on 14 July 2026. Windows Server 2016 follows on 12 January 2027. The catch is the ESU price. With SQL Server 2014, ESUs on Azure VMs were free. SQL Server 2016 ESUs aren't, and they're billed through Azure Arc or the SQL IaaS Agent extension.
- openVulnerability scans already flag SQL Server 2016 instances as unsupported.
- recurringA vendor certifies its application on Windows Server 2016 and nothing newer, and it hasn't answered your emails.
- blockedNobody's sure which SQL Server instances are on Standard and which on Enterprise, or which cores have Software Assurance.
- openThose servers run .NET Framework 4.6.2 apps too, and 4.6.2 support ends the same day as Windows Server 2016.
The estate, before and after
Before: applications on Windows Server and SQL Server 2016
Line-of-business and vendor applications ran on Windows Server 2016 hosts with SQL Server 2016 underneath, plus SSIS packages, Agent jobs and linked servers. Scans flagged the instances, and nobody could say which edition or licence coverage each one had.
After: supported Windows and SQL Server, tracked in Azure Arc
We moved the servers to Windows Server 2025, on-premises or on Azure VMs, and the databases to a current SQL Server release or Azure SQL Managed Instance. Azure Arc holds the inventory, and the few servers on ESUs each have an exit date.
How we run it, phase by phase.
5 phases take you from Windows Server 2016 and SQL Server 2016 to Supported Windows and SQL Server, on-prem or Azure. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Instance and licence inventory
Start with the inventory. Record edition, version, CU level, cores, Software Assurance status and owning application for every Windows Server and SQL Server instance. Azure Arc collects much of it, and connecting servers to Arc is free.
- phase 02
Path per server
Each server gets one path. Upgrade it in place, rebuild it side by side, move it to Azure SQL Managed Instance or an Azure VM, retire it, or buy ESU time. Windows Server 2025 supports non-clustered in-place upgrades across up to four versions, so a 2016 box can go straight to 2025.
- phase 03
Database compatibility testing
Restore production backups onto the target SQL Server version, run the workload at the old compatibility level first, then raise it with Query Store capturing plan regressions.
- phase 04
Application and vendor sign-off
Check each vendor's support matrix, test logins, linked servers, SSIS packages, SQL Agent jobs and service accounts, and record who signed off.
- phase 05
Cut-over and ESU clean-up
Upgrade or migrate in maintenance windows with a rollback point. Cancel ESU subscriptions as each server leaves the unsupported version so you stop paying hourly.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every server has a decided path and an owner
We marked each Windows Server and SQL Server instance for in-place upgrade, side-by-side rebuild, Azure SQL Managed Instance or an Azure VM, retirement, or a dated ESU bridge.
- result 02
The licence position is known per instance
Every instance is in the inventory with edition, version, CU level, cores, Software Assurance status and owning application. Most of that came from Azure Arc.
- result 03
Compatibility levels were raised only after testing
We ran every workload on the new SQL Server at the old compatibility level to start with, and Query Store recorded plan regressions before each level went up.
- result 04
Vendors and app owners signed off in writing
For each application we tested logins, linked servers, SSIS packages, SQL Agent jobs and service accounts, and recorded who signed off against the vendor's support matrix.
- result 05
ESUs are a bridge with an exit date
Servers on ESUs have exit dates, and once one leaves the old version its subscription is cancelled. You stop paying for it that day.
Risks we plan for
-
ESUs used as a plan instead of a bridge
ESUs cover critical security fixes only, for three years at most. Buy them without an end date and teams tend to keep renewing until the last year.
-
Query plan regressions
A newer cardinality estimator can slow a few critical queries. Testing at the old compatibility level and Query Store hints keep this contained.
-
SSIS, SSRS and linked servers
They get forgotten more than anything else in the estate and take longest to move. Packages that hold credentials or point at file shares are the worst.
-
Clustered and Always On instances
Failover clusters can't take the simple in-place path. They need a rolling or side-by-side plan, with listener and DNS changes worked out in advance.
Where AI helps, and where it needs guardrails
For .NET modernization, Microsoft points people to the GitHub Copilot modernization agent. Azure Arc already collects SQL inventory, and an assistant can summarize it. We have AI draft the per-server plan and the SQL compatibility notes, then test every change ourselves. Put an MCP server with read-only access over the Arc data and anyone can ask which servers are still on 2016.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Windows Server and SQL Server inventory with licence position
yours to keep - document02
Upgrade, migrate, retire or ESU decision per server
yours to keep - tests03
Compatibility test results with plan regressions and fixes
yours to keep - runbook04
Cut-over runbooks with rollback points
yours to keep - code05
ESU subscription list with an exit date for each server
yours to keep
Platforms and services on this move
Services involved
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01assurance
- Proof that the controls did their job, collected as you go. Think signed reviews, test results and admission logs, kept for every release.in context →
- 02Extension
- Your own code sitting on top of the standard product, which stays untouched underneath. Business Central extensions are written in AL, Finance and Operations ones in X++.in context →
- 03Extended Support
- IBM's paid support once a release's normal support has ended. Security Verify Access 10.0.x moved onto it in April 2026, except on hardware appliances, so check your contract still covers you.in context →
- 04Rollback
- Going back to the version you ran before an upgrade, using the backups and the untouched old install you kept for that.in context →
- 05Extended Security Updates
- Microsoft's paid way to keep getting Critical and Important security fixes after support ends. For Windows Server 2016 you can buy up to three years of it, and then it stops.in context →
- 06Azure Arc
- Microsoft's tool for managing servers that sit outside Azure, in a company's own data center or another cloud. The inventory costs nothing, and it's how you buy 2016 ESUs month by month.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Should we buy Extended Security Updates?
Buy them for the servers that genuinely can't move in time, and put an exit date on each one. They're billed through Azure Arc or Azure VMs, and there's a pay-as-you-go option without Software Assurance. You get critical fixes, and no support for the old version.
02Is moving to Azure cheaper than upgrading on-premises?
Sometimes. Azure Hybrid Benefit lets you reuse Windows Server and SQL Server licences, and Azure SQL Managed Instance removes patching. It depends on how many cores you run, your Software Assurance coverage and whether the hardware is due for refresh anyway. We price both.
03Can we upgrade straight from SQL Server 2016 to the newest version?
Usually yes, by restore or detach and attach onto a new instance, which also gives a clean rollback. We test the workload at the old compatibility level before raising it.
04Do you handle the application side too?
Yes. When an upgrade pulls in .NET Framework, IIS or SSIS changes, which it often does, our application engineers handle them.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case studyea1438c6 - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it