If you run SQL Server 2016 or Windows Server 2016 anywhere in your estate, this article is for you, and the timing matters more than you think. On 14 July 2026, SQL Server 2016 reaches the end of extended support. Windows Server 2016 follows on 12 January 2027. After those dates, the patches stop. This is one more reason to do what the smartest Nordic companies are already planning, which is to get out of the data center.
It is the clearest modernization deadline most IT teams will get this year, and the cheapest one to act on early. Here is what actually happens when support ends, the real options in front of you, and the steps to take before the clock runs out.
Why this modernization deadline is real
Microsoft retires every product on a published schedule, and these two are next in line. SQL Server 2016 loses extended support on 14 July 2026, according to the Microsoft lifecycle page; Windows Server 2016 reaches the same point on 12 January 2027. Neither disappears. Your servers keep running, your databases keep answering queries, and nothing breaks at midnight. That is what makes the date dangerous. The risk is invisible until it is not.
It does not arrive alone. It lands on top of rising VMware costs, aging colocation contracts, and AI projects that stall because the data is stuck on old infrastructure. Every one of those points the same way: out of the data center, onto a modern platform. The end-of-support date is just the one with a fixed time on it, which makes it the easiest place to start.
A lot of Finnish and Nordic companies still run both. SQL Server 2016 especially sits under line-of-business applications nobody wants to touch, because they work. The owner left three years ago, the integration is undocumented, and the database is load-bearing in a way no architecture diagram admits. That is the workload most exposed when the patches stop.
What end of support actually costs you
End of support means no more security updates. After 14 July 2026, any new vulnerability in SQL Server 2016 stays open. Forever, because there is no team left writing patches. Windows Server 2016 hits the same wall in January 2027. For a database holding patient records, grid telemetry, or financial transactions, an unpatched platform is an audit finding waiting to happen.
The compliance angle is sharper than the security one for many boards. Software that can no longer receive security fixes is hard to defend to an auditor, an insurer, or a customer doing due diligence. The question stops being “is it patched” and becomes “why are you still on it.”
Microsoft offers a bridge. Extended Security Updates buy up to three more years of critical patches, but the price climbs every year, and by year three the bill often rivals a proper upgrade. Paying to stand still means paying twice: once to delay, again to do the work anyway. One provider-specific exception is worth knowing, and we come back to it below.
Your modernization options, from worst to best
- Option one is to do nothing and buy time with ESUs. This is the path of least resistance and the highest long-term cost. You keep the lights on, you stay technically covered for a while, and you spend money that buys you no new capability. Sometimes a single workload genuinely needs this bridge while you sort out a bigger migration. As a strategy for the whole estate, it is a slow and expensive way to arrive at the same decision later.
- Option two is to rehost the workload in the cloud as it stands, often called lift and shift. You move the SQL Server or Windows Server virtual machine to a major cloud, AWS or Azure, with minimal change. Either way, the workload leaves the data center and lands on a platform someone else keeps running. One detail is worth knowing here. When you run SQL Server 2016 or Windows Server 2016 on Azure, Microsoft provides Extended Security Updates at no additional cost beyond the price of running the machine, as Microsoft states in its Extended Security Updates guidance. The same patches carry a rising annual fee on-premises and on other platforms. That is a real factor to weigh, not a reason to send everything to one provider. Rehosting on any major cloud buys you breathing room without forcing an application rewrite on day one, and it gets the workload out of the data center, which is the move that opens up everything that follows.
- Option three is to refactor the database onto a managed service, and for SQL Server this is the most interesting move available. Instead of carrying a full Windows and SQL Server installation that you have to patch, size, and babysit, you move the database into a managed cloud database. Azure SQL Managed Instance and Amazon RDS are two examples. Both run the operating system, the patching, the high availability, and the backups for you. Your team stops doing maintenance that creates no value and starts spending its time on the data itself. Refactoring takes more thought than a lift and shift, because you have to check compatibility and adjust a few things, but the payoff is permanent. You never have to run another SQL Server end-of-support project for that database again, because there is no version to reach end of life.
- Option four applies to the Windows Server side. Many of the workloads sitting on Windows Server 2016 do not need a server at all anymore. A web application can move to a managed app service. A batch job can become a container or a function. When you replatform like this, the end-of-support problem dissolves, because you are no longer responsible for the operating system underneath. Not every workload qualifies, but more do than most teams assume before they look.
Why refactoring SQL is the modernization move worth making
Here is what we see regularly in client work. Teams treat the end-of-support date as a chore: find the old servers, upgrade them, move on. That mindset gets you to SQL Server 2022, and then you do the whole thing again when 2022 reaches its own end of support. The deadline becomes a recurring tax.
The teams that get the most out of this moment ask a different question. Not how do we upgrade this server, but does this database need to be a server at all. For a large share of SQL Server 2016 workloads, the honest answer is no. The database needs to be available, secure, performant, and backed up. It does not need you to own a server licence, a patch cycle, and a 2 a.m. failover plan to deliver those things. Moving to a managed database hands all of that to the platform, whichever provider you choose.
Modernization is the step that everything else waits on. You cannot put AI to work on data locked inside a server nobody wants to touch, and you cannot move fast on a platform you spend your weekends patching. Get the database onto a modern cloud platform and the next moves, analytics, AI, automation, finally become possible. That is why refactoring is a genuinely good first step, not just a way to clear a deadline. It is the move that turns a forced upgrade into real progress.
Where local data residency fits
There is a Nordic dimension to this worth flagging now. Local data residency is getting easier to reach. Microsoft is building a datacenter region in Southern Finland, in Espoo, Kirkkonummi and Vihti, and the other major providers keep expanding their Nordic and European footprint. For companies in healthcare, energy, and the public sector, data location is often the deciding factor in a cloud move. If local and regional options are arriving, the smart play is to design your modernization with data residency in mind from the start, whichever platform you choose, so the workloads you move now are ready to sit where your rules require. You do not wait for a single region to start modernizing. You modernize in a way that keeps your options open.
The modernization steps to take, in order
Start with an inventory. You cannot plan a migration for servers you cannot see. Find every instance of SQL Server 2016 and Windows Server 2016, what runs on it, who depends on it, and how sensitive the data is. Most organizations are surprised by what turns up.
Then assess each workload and sort it. Not every database deserves the same treatment. Some are simple and can move to a managed service quickly. Some are tangled and need a careful rebuild. Some are genuinely better off retired. A short, hands-on review that sizes the effort per workload is the difference between a plan and a wish. At Cloud2 we do this with a small set of workloads first, sizing each one honestly before anyone commits to a direction or a platform.
Pick a destination per workload, not one rule for all of them. The output of the assessment is a simple decision for each system: rehost, refactor, replatform, or retire, and on which platform. Most estates end up with a mix, often across more than one cloud. That is correct. Forcing every workload down the same path, or onto the same provider, is how migrations go over budget.
Pilot before you commit at scale. Take one representative workload all the way to its destination, prove the performance and the cutover, and learn what your particular environment throws at you. Then migrate the rest in waves, hardest dependencies first or quickest wins first depending on your risk appetite. Decommission the old servers as you go, because a half-finished migration that leaves the originals running gives you the cost of two estates and the safety of neither.
The deadline does the hardest part of the work for you. It tells you when. The only real decision left is whether you spend the next year upgrading servers you will have to upgrade again, or whether you use the date as the reason to get those workloads out of the data center and onto a platform that never reaches end of support in the first place. If you are the IT director or CIO who has to carry this forward inside your own organization, the deadline is not a threat. It is your mandate to act.
If you want to know which of your workloads should move and where, that is exactly what a Cloud Review is for. We are not tied to one vendor, so we map what you are running, size the effort honestly, and give you a clear picture of your options across platforms before you commit to anything. Booking one now, well ahead of July, is the difference between modernizing on your terms and migrating in a panic.
