Small Business Managed IT Services: Canadian Guide (2026)
What Canadian small businesses need to know about managed IT services in 2026: what's included, what it costs, when to switch, and how to choose the...
12 min read
Adrian Ghira
:
Published
On January 12, 2027, Microsoft stops issuing security updates for Windows Server 2016.
The server will not stop working. Nothing will visibly break. Files will still open, the line-of-business application will still run, and users will notice nothing at all. That is precisely why this deadline gets missed. There is no outage to force a decision, so the decision does not get made, and the consequences accumulate quietly until an auditor, an insurer, or an attacker surfaces them.
If Windows Server 2016 is running anywhere in your environment, you have roughly four months in which this is a planning exercise. After that it becomes an emergency project priced accordingly, or a paid extension that costs more each year you keep it.
There is a second date that makes this more complicated than a single migration, and it has already passed. SQL Server 2016 left extended support on July 14, 2026, about six months ahead of the operating system. Any environment running SQL Server 2016 on Windows Server 2016 has two overlapping obligations rather than one, and the sequence in which you address them is not the sequence most businesses assume.
This article is written for Canadian businesses with 20 to 200 users who need to make a decision this fall and bring a defensible number to an owner, a CFO, or a board. It covers what actually changes in January, the three real options and what each one costs, the compatibility traps that derail migration plans, when Extended Security Updates are the right answer, and how to structure a 2027 technology budget that gets approved once rather than debated three times.
Windows Server 2016 shipped in October 2016 under Microsoft’s ten-year lifecycle model: five years of mainstream support, then five years of extended support. Mainstream support ended in January 2022, which means the platform has already been receiving security updates only for several years. January 12, 2027 is the end of extended support, and after it Microsoft provides no security updates, no non-security fixes, and no technical assistance outside the paid Extended Security Updates program.
The consequences fall into four distinct categories, and it is worth separating them because they arrive on different timelines.
Unpatched vulnerabilities accumulate permanently. Any vulnerability discovered in Windows Server 2016 after that date stays open on your system indefinitely. This is not a theoretical risk profile that degrades gradually; it compounds with every patch cycle you miss. Internet-facing services and systems holding regulated data are the immediate concern.
Audit and compliance findings. Auditors treat an unsupported operating system as a control deficiency. If your organization undergoes any form of security review, whether a SOC 2 examination, a customer security assessment, or a regulatory review, an unsupported server is a finding you will have to explain and remediate.
Cyber insurance treatment. Underwriters ask about unsupported operating systems on the application. A yes creates a real risk of a premium increase, a sub-limit, or an exclusion. More seriously, if an incident traces back to a vulnerability on an unsupported platform, you are in the territory where carriers deny claims.
Third-party vendor support withdrawal. This is the consequence businesses least anticipate and feel most acutely. Software vendors progressively drop unsupported operating systems from their support matrices. Your line-of-business application vendor may already have a statement about it. At the point where your accounting system, your ERP, or your practice management software declines to support you on Server 2016, the migration stops being a security decision and becomes an operational one, on the vendor’s timeline rather than yours.
SQL Server 2016 left extended support on July 14, 2026. If you are running it, you are already unsupported, today, and the four consequences above already apply to your database platform.
This creates a sequencing problem. Many businesses plan a single project: move the server, move everything on it, done. But the database frequently has to move first and separately, for two reasons.
First, the compatibility matrix constrains you. Microsoft’s support matrix caps SQL Server 2016 at Windows Server 2019; the oldest SQL version supported on Windows Server 2022 is SQL Server 2017, and Windows Server 2025 raises that floor again. You cannot simply carry an old SQL instance onto a new operating system and consider the job done.
Second, the application sitting on top of the database usually has its own supported-version list. Upgrading SQL Server may require an application upgrade, which may require vendor involvement, testing, and a change window. That is a project with a dependency chain, and it is the item most likely to blow a compressed timeline.
The practical guidance: inventory your SQL instances before you plan anything else, and confirm with each application vendor which SQL version and which operating system they support today, in writing.
Option one: upgrade in place. Windows Server 2025 supports in-place upgrades from Server 2012 R2, 2016, 2019, and 2022 using installation media. Where the hardware is modern enough, the application is compatible, and the role is straightforward, this is the fastest and cheapest path.
The caveats matter. In-place upgrades carry rollback complexity, they inherit whatever configuration debt has accumulated over ten years, and they require the existing hardware to be supported by the new operating system and by the server vendor’s driver and firmware matrix. Hardware purchased in 2016 or 2017 is frequently at or past the end of its own supported life, which turns an operating system project into a hardware project.
Cost profile: licensing plus labour, with no capital expenditure. Fastest to complete. Highest risk of carrying forward existing problems.
Option two: replace the hardware and migrate. New server, clean operating system installation, roles and data migrated, old server decommissioned. This is the option most 20 to 200 user businesses with on-premise workloads end up choosing, because their hardware refresh cycle and the operating system deadline coincide.
Cost profile: capital expenditure on hardware, new licensing, and more labour than an in-place upgrade, offset by a clean configuration, a fresh warranty, and a platform that will comfortably outlive the next operating system transition. Consider hardware-as-a-service arrangements if converting capital expenditure into a predictable monthly operating expense is preferable, which for many owner-operated businesses it is.
Option three: move the workload to Azure or another cloud platform. For file services, application hosting, and databases, this eliminates the recurring end-of-support cycle for infrastructure you no longer own. It is the right answer more often than it was three years ago, and it is still not the right answer universally.
Cost profile: no capital expenditure, higher and permanent operating expense, migration labour comparable to or above a hardware replacement. The honest assessment: cloud migration usually costs more over five years than an on-premise refresh for a workload that is stable, predictable, and not growing. It wins on flexibility, resilience, geographic access, and the elimination of future hardware and operating system cycles. Run the five-year comparison rather than accepting either default.
The fourth option nobody lists: retire the workload. Before budgeting a migration, ask what the server actually does. We regularly find Server 2016 machines running a single legacy application used by two people, a file share whose contents have not been accessed in three years, or a print server that could be replaced with a cloud service. A deadline is a good reason to conduct an inventory, and the cheapest migration is the one you do not perform.
If your Server 2016 machine is a domain controller, treat it differently from every other server in the environment.
In-place upgrading a domain controller is technically supported and generally a false economy. The better practice is to stand up new domain controllers on the new operating system, allow replication to complete, transfer the roles, verify, and then demote and decommission the old ones. This approach gives you a working rollback position throughout, avoids carrying forward accumulated directory and policy issues, and produces a directory service you can actually document.
Domain controller migration is also where an ill-considered project causes the most damage, because authentication failure is a total outage rather than a degraded service. If your environment has a single domain controller, which is more common in the 20 to 200 user range than it should be, this deadline is also an opportunity to fix a genuine single point of failure.
Extended Security Updates are Microsoft’s paid mechanism for continuing to receive security patches after end of support, available for up to three years. The pricing structure is deliberately unfriendly: roughly 75% of the original licence cost in the first year, escalating in subsequent years. It is designed to be more expensive than migrating, because it is intended as a bridge rather than a destination.
There are two legitimate scenarios.
A hard application dependency with a known resolution date. A line-of-business application that genuinely cannot run on a newer operating system, where the vendor has a committed release date for a version that can. Buying twelve months of coverage to align with that release is a rational decision.
A migration already in flight that will not complete in time. If the project is funded, scoped, and underway, and the completion date lands in the first quarter of 2027, purchasing a single year of coverage is cheaper and safer than compressing the migration into an unsafe timeline.
What is not a legitimate scenario: using Extended Security Updates because the decision was not made in time. In that case you are paying an escalating premium to defer a project whose cost also rises, and doing so with an unsupported platform on your insurance application in the interim.
Three checks to complete before you commit a budget number. Each one has cost your peers a project restart.
Operating system to database version. Confirm which SQL Server version your target operating system supports, and which version your application requires. The intersection of those two constraints determines your migration path, and occasionally it forces an application upgrade you had not budgeted.
Vendor support statements, in writing. Ask every line-of-business software vendor which operating system and database versions they support today, and which they will support in twelve months. A verbal assurance from a support representative is not a support statement. This is the single most common cause of a migration being halfway complete when someone discovers the application is not supported on the new platform.
Hardware and firmware compatibility. If you are keeping existing hardware, confirm it appears on the server manufacturer’s supported list for the target operating system, and that current firmware and drivers exist. Ten-year-old hardware frequently does not, and discovering that after the licence purchase is an avoidable expense.
September and October are when most of the businesses we work with set next year’s technology number. Five categories belong in it, and three of them will be larger this year than last.
Infrastructure and end of support. The Server 2016 and SQL Server 2016 work above, plus any Windows 10 devices still in the fleet and any network hardware past its supported life. This is the category with a fixed external deadline, which makes it the easiest to get approved.
Security controls at the level now expected of you. Canadian cyber insurance underwriters and enterprise customers have converged on the same list: phishing-resistant multi-factor authentication rather than SMS codes, endpoint detection and response at full coverage rather than partial, immutable backups with a tested and documented restore, and a documented incident response plan. If any of those are partial today, they are budget items, and they are increasingly the difference between insurable and uninsurable.
Licensing tier corrections. Many Canadian SMBs are on a Microsoft 365 tier that does not include the security capability they have been told to implement. The comparison worth running is the cost of moving to the correct tier against the cost of purchasing equivalent third-party tools, and in most cases consolidating onto the higher Microsoft tier is cheaper and simpler to operate.
Hardware refresh. Workstations and laptops on a defined cycle rather than replaced on failure. Replacement-on-failure feels cheaper and is not, once you account for the productivity cost of a failure at the wrong moment and the premium paid for expedited purchasing.
Projects and strategic work. Whatever the business is actually trying to accomplish next year. This is the category that gets cut when the four above were not planned for, which is the argument for planning them.
Presenting it. A number that gets approved once has three properties: it separates deadline-driven work from discretionary work, it attaches each item to a business consequence rather than a technical description, and it shows what the alternative costs. Server 2016 remediation is not “operating system upgrade, $X.” It is “removes an unsupported platform that our insurer and our largest customer both ask about, before the January deadline, at $X. Deferring to Q2 adds Extended Security Update costs of $Y and leaves the exposure open through renewal.”
September: inventory. Every server, its operating system, its role, its hardware age, the applications it hosts, and the SQL versions present. Identify which workloads could be retired instead of migrated. This is a week of work and it changes the budget more than any other step.
October: decide and budget. Option per workload, vendor support statements confirmed in writing, quotes obtained, and the number into the 2027 budget while the budget is still being written.
November: test. Application compatibility in a test environment, restore verification so you know your rollback position is real, and a documented cutover plan per workload.
December and January: execute. Migrate in priority order, internet-facing and regulated-data systems first, domain controllers with a clean migration rather than an in-place upgrade, with change windows agreed in advance.
The decision point. If by late November a specific workload clearly will not complete in time, that is when you buy Extended Security Updates for that workload deliberately, rather than discovering the need in January.
GAM Tech has supported Canadian businesses with 20 to 200 users since 2012 from nine markets across Alberta, British Columbia, Ontario, and Quebec.
On end-of-support migrations specifically, our engagement includes the full environment inventory and dependency mapping described above, vendor support verification so nobody discovers an incompatibility mid-project, the five-year comparison between on-premise refresh and Azure migration presented honestly rather than steered toward whichever we would rather sell, hardware as a service where converting capital expenditure to operating expenditure suits the business better, and after-hours cutover work performed by internal staff who know your environment rather than a subcontracted team meeting it for the first time at 11 p.m.
We are SOC2 certified, B Corp certified, and Great Place to Work certified, and we run on EOS with fully documented core processes. Our support team is internal and never outsourced, with a 5-minute response commitment delivered on 99%+ of tickets. Project packs are included in our managed services agreement, which means migration planning and documentation are not a separate scoping exercise.
Silver plans start at $110 per managed device per month with a $1,000 monthly minimum. Gold plans add the layered cybersecurity stack.
What happens if we do nothing after January 12, 2027? The server keeps running. Microsoft stops issuing security updates, so every vulnerability discovered after that date remains open indefinitely. Auditors treat the platform as a control deficiency, cyber insurers treat it as an unsupported system on your application, and software vendors progressively withdraw support. The risk compounds monthly rather than arriving all at once, which is what makes it easy to defer.
How much do Extended Security Updates cost? Approximately 75% of the original licence cost per year, escalating in subsequent years, available for up to three years. It is priced to be more expensive than migrating. It makes sense as a bridge when a migration is already underway or when a vendor has a committed release date, and it makes no sense as a substitute for a decision.
Can we upgrade Windows Server 2016 in place to Server 2025? Yes, in-place upgrades are supported from Server 2012 R2, 2016, 2019, and 2022. Verify application compatibility and hardware support first. For domain controllers, prefer building new controllers on the new operating system and migrating roles rather than upgrading in place, because it preserves a rollback position and avoids carrying forward directory issues.
Should we move to Azure instead of buying new hardware? Run the five-year comparison rather than accepting a default. For a stable, predictable workload that is not growing, an on-premise refresh is frequently cheaper over five years. Cloud wins on flexibility, resilience, geographic access, and eliminating future hardware and operating system cycles. Both answers are legitimate; the wrong approach is choosing without the comparison.
What about our SQL Server 2016 databases? SQL Server 2016 left extended support in July 2026, so it is already unsupported. It usually has to move first and separately, because the compatibility matrix constrains which SQL versions run on which operating systems, and because upgrading SQL may require an application upgrade with vendor involvement. Inventory your SQL instances before planning anything else.
How long does a server migration take for a 50-user business? For a single straightforward file and application server, typically two to four weeks of elapsed time including testing, with a cutover window of a few hours. Environments with multiple servers, a domain controller, a database with an application dependency, or a vendor upgrade in the chain run six to twelve weeks. The variable is almost never the migration itself; it is the application and vendor dependencies.
Will our line-of-business application still be supported? Ask the vendor in writing which operating system and SQL versions they support today and in twelve months. Do not rely on a verbal assurance from a support call. Unverified vendor support is the most common reason a migration stalls after it has started.
How does an unsupported server affect our cyber insurance? Underwriters ask about unsupported operating systems. A yes can produce a premium increase, a sub-limit, or an exclusion. If an incident traces to a vulnerability on an unsupported platform, you are in the territory where claims get denied, particularly if the application described your environment differently.
What should a Canadian SMB budget for IT in 2027? Rather than a percentage of revenue, build it from five categories: infrastructure and end-of-support work, security controls at the level insurers and enterprise customers now expect, Microsoft licensing tier corrections, a defined hardware refresh cycle, and strategic projects. The first three will be larger for most businesses this year than last.
Do we still need on-premise servers at all? Many businesses in this size range no longer do, and some genuinely still do, usually because of a line-of-business application with an on-premise requirement, a large local data set where bandwidth economics matter, or a regulatory data location constraint. This deadline is a good moment to test the assumption rather than replace like for like out of habit.
What should we look for in a partner for a server migration? Someone who inventories and maps dependencies before quoting, who obtains vendor support statements in writing, who presents the on-premise versus cloud comparison honestly instead of steering it, who will perform cutover with staff who already know your environment, and who tells you which workloads should be retired rather than migrated.
January 12, 2027 is not going to move, and the servers that are running Windows Server 2016 today are, in our experience, largely the same servers that were running Windows Server 2012 R2 until someone was forced to act. The difference between a planned migration and a forced one is roughly the difference between a budgeted project and a premium-priced emergency, plus the interval where an unsupported platform sits on your insurance application.
If you are not certain what is running in your environment, that is the place to start. GAM Tech provides infrastructure assessments across all nine of our Canadian markets, covering the full inventory, dependency mapping, vendor support verification, and a costed set of options you can bring straight into your 2027 budget conversation. Contact us before the fall budget cycle closes.
What Canadian small businesses need to know about managed IT services in 2026: what's included, what it costs, when to switch, and how to choose the...
A managed service provider (MSP) delivers ongoing IT services under a monthly contract. Learn what MSPs do, how they price, and how to choose one in...
Managed IT services outsource tech support, security, and strategy to an MSP. Learn what they cover, how they work, and what they cost in Canada in...