Your server has an expiry date: January 12, 2027
The server at the back of the utility room works. It has never crashed. Nobody touches it — and that is precisely the problem: on January 12, 2027, Microsoft stops protecting it. Five months remain, and this time the paid reprieve is far less generous than the one offered for Windows 10. Here is how to find out what that server still does, and the only three ways out.
In most Quebec small and mid-sized businesses, there is a server nobody talks about. It sits in a room at the end of the hallway, sometimes in a converted closet, with a UPS that beeps once a year. It runs Windows Server 2016. It was installed by someone who no longer works there. And it works — which is exactly why the file never reaches the executive desk.
On January 12, 2027, that server stops receiving security updates. It will not shut down. It will keep serving files, the line-of-business application and everyone's logins, just as it did the day before. The only thing that changes is that from that date forward, every newly discovered flaw in Windows Server 2016 stays open permanently.
What exactly is ending
Mainstream support for Windows Server 2016 ended in January 2022. For four years, the product has been living on extended support: security fixes only, no new features. That last safety net disappears on January 12, 2027.
And this deadline does not arrive alone. Several pieces of the same ecosystem have already fallen or are falling at the same time:
- SQL Server 2016 left support in July 2026 — last month, in other words. Many SMB line-of-business applications rely on that database, often installed on the very same server. And the paid reprieve is now a real expense: where the previous generation gave access to fixes at no additional cost in certain scenarios, ESU for SQL Server 2016 has to be purchased.
- Windows Server 2012 and 2012 R2 complete the third and final year of their paid reprieve programme in October 2026. If you still have one, your countdown is shorter than the 2016 one.
- Exchange Server 2016 and 2019 have been out of support since October 2025. An unpatched on-premises mail server is, today, one of the most profitable targets in existence.
- Windows Server 2019, for its part, holds until January 2029. Migrating to that version in 2026 would be buying two years.
Put differently: this is not one server to deal with, it is a web of dependencies to untangle.
This time, the paid reprieve is a bad bridge
For Windows 10, the Extended Security Updates (ESU) programme at least offered an exit you could put a number on: a fixed price per device, doubling each year. On the server side, the arithmetic is considerably less welcoming, and four details rule the option out for most SMBs.
First detail: billing is per core, with a 16-core minimum per server. The annual price represents a substantial fraction — sometimes the entirety — of a new Windows Server licence. Paying the equivalent of a new licence every year to receive nothing but security patches is a trade-off that rarely holds up.
Second detail, the decisive one: eligibility. Server ESU requires licences covered by Software Assurance through a volume licensing programme, or an equivalent server subscription. OEM licences — the ones that came preinstalled with the server, which is to say the vast majority of the SMB installed base — are not eligible. Neither are retail licences. And unlike previous generations, SPLA is not available for Windows Server 2016: the door is narrower than it used to be. For many businesses, ESU is therefore not an expensive option — it is not an option at all.
Third detail: enrolment is cumulative and capped. Joining in year two means paying for year one as well, and the programme ends permanently after three years. The bridge leads to January 2030, and no further. As for free coverage, it does still exist — but only for workloads already hosted by Microsoft: Azure virtual machines, Azure VMware Solution, Azure Local, Azure Stack. Which, by definition, does nothing for the server in the utility room.
Fourth detail, often discovered too late: even when purchasing through volume licensing, the server must be registered in Azure Arc for the patches to activate. The "reprieve" therefore assumes a small piece of management infrastructure to put in place — on a server you were specifically hoping never to touch again.
The conclusion is the same as for workstations, only sharper: the reprieve is a bridge, not a destination. Except that this time the bridge has a steep toll, restricted access, and it ends in three years.
How do you know whether you are eligible? The question takes minutes to settle: your licensing partner can confirm whether your Windows Server licences are covered by Software Assurance or by a subscription. It is the first thing to check, because the answer either removes an option or keeps it on the table before you start comparing scenarios at all.
The real question: what does that server still do?
Before choosing a destination, you need to know what you are moving. This is the step almost everyone skips, and it is the one that explains the unpleasant surprises mid-migration.
An SMB server typically accumulates five to ten roles, half of which were added over the years without documentation:
- The corporate directory (Active Directory), DNS, DHCP — which means: everyone's logins
- File shares, with permissions accumulated over a decade
- The line-of-business application and its database
- The virtualization host, running other servers
- Print queues, remote access, scanning from the multifunction printers
- The scheduled task nobody documented, which sends the Friday report
- And sometimes, the destination for your backups — which means the server at risk is also holding your safety net
That last point deserves a reminder: a backup living on the server it is meant to protect is not a backup. It is the same subject as the myth of automatic backup in Microsoft 365 , transposed to the utility room.
Inventorying those roles is a few hours' work with the right tools, and it is the first step of any serious audit . Without it, the question "do we upgrade or replace?" has no valid answer.
Three ways out, not four
Once the inventory is done, the options fit on three fingers.
1. Upgrade the operating system in place. To Windows Server 2022 or 2025, keeping the hardware. It is the fastest route on paper, but it often runs into two walls: hardware from 2016-2018 is reaching the end of its warranty life, and the line-of-business application is not always certified on recent versions. Confirm with the software vendor before buying the licence, not after.
2. Replace the server. New hardware, current operating system, warranty clock reset. This is the logical choice when one or more roles must stay on site: a heavy line-of-business application, a large volume of files, a latency constraint, a contractual data-residency requirement.
3. Retire the roles, one at a time. This is the most interesting option, and the least often evaluated. Many of these roles no longer need a physical server: file shares can move to SharePoint and OneDrive, the directory to Microsoft Entra ID, the line-of-business application to the vendor's hosted version, backups to a cloud service. At the end of the exercise, some businesses discover there are no longer enough reasons to have a server at all. It is a migration to plan , not a switch to flip — but it settles the problem for good, rather than deferring it to the next expiry date.
The fourth option — doing nothing — is not an option, for three reasons that have nothing to do with technology. Law 25 requires reasonable security measures: arguing "reasonable" with a directory server that has gone unpatched for months is a losing exercise. Your insurer, at renewal, explicitly asks whether your systems are supported by their vendor. And your software vendors will stop certifying their own updates on an unsupported operating system.
Counting backwards
Five months is comfortable — provided you count backwards from January 12 rather than forwards from today.
August and September: inventory and dependencies. Which roles run where, which database version, which vendor needs to confirm what. This is also the moment to call the vendor of your line-of-business application: their response times, in practice, are your real critical path.
October: decision and budget. A server migration lands squarely in 2027 budget season. That is a useful coincidence: present the file once, with three costed scenarios, rather than coming back in January in emergency mode.
November: ordering. Server hardware lead times are measured in weeks, not days, and they stretch at year-end. Ordering in November to install in December is realistic; ordering in December is not.
December and early January: cutover. Avoiding your critical periods — fiscal year-end, inventory, payroll. And with a rollback plan written and tested before you begin.
The server at the back of the utility room has an expiry date. The only decision still yours to make is whether you choose it this fall, with a plan and three quotes — or whether you take it in January, with an emergency quote and a week of downtime.
At MMO Techno, we run this exercise regularly for Quebec SMBs: an inventory of the roles actually in use, validation of software dependencies with the vendors, a costed comparison of the three scenarios, and a cutover planned outside your critical periods. If you are not sure what your server still does, this is the best time of year to find out. Let's talk .