Windows Server 2022 Hotpatching Extended to October 2027

What did Microsoft actually extend, and why does it matter?

Microsoft has extended the availability of hotpatching for Windows Server 2022 (Datacenter: Azure Edition) through October 2027. In plain terms, servers running that edition can keep receiving most of their monthly security updates without rebooting for roughly another year and a half beyond the timeline many admins had penciled in. It buys planning time before committing to Windows Server 2025.

This matters because reboots are not free. Every restart on a production web or application server means dropped connections, cold caches, a few minutes of downtime, and a maintenance window someone has to own at an awkward hour. Hotpatching lets you install in-memory security fixes to running code, so the patch lands without the machine going down.

If you run always-on workloads — ecommerce, APIs, member portals, anything where a reboot is a visible outage — this extension is the difference between four planned restarts a year and roughly twelve. For teams that value uptime and predictable maintenance, that is a real operational win, not a footnote.

How does Windows Server hotpatching actually work?

Hotpatching works on a quarterly rhythm built around two kinds of months. Understanding the cycle is the whole point — it tells you exactly when you can and cannot avoid a reboot.

• Baseline months (January, April, July, October): a cumulative update installs and the server does reboot. This resets the patch baseline for the quarter.
• Hotpatch months (the two months after each baseline): security fixes are applied directly to the in-memory code of running processes. No reboot required.

So in a normal year you reboot about four times for patching instead of every month. The hotpatch updates are smaller, install faster, and carry the same security content as the equivalent regular cumulative update — you are not trading safety for convenience.

There are limits worth knowing. Hotpatching covers most OS security fixes, but some updates — certain kernel changes, .NET updates, and non-security fixes — still require a baseline-style reboot. Hotpatching is also an edition- and platform-specific feature, not something you switch on for any random Windows box.

The mental model that saves you grief: hotpatching reduces how often you reboot, not whether you ever reboot. Plan for four solid maintenance windows a year and treat everything in between as a bonus.

Where is hotpatching free, and where does it cost money?

This is the part that trips people up, because the answer changed between Windows Server 2022 and 2025. The short version: on 2022 Azure Edition it is included, while on 2025 outside Azure it became a paid subscription.

Pricing for the Server 2025 subscription is a realistic public figure of around $1.50 per CPU core per month; confirm current numbers in Microsoft's documentation before you budget, since cloud pricing shifts. What most coverage glosses over: the 2022 extension means you do not have to rush a migration just to keep no-reboot patching — you have a free runway until late 2027 on the edition you may already be running.

Does this change how you should choose hosting in 2026?

For most website owners the honest answer is: only if you are specifically running Windows Server workloads. The vast majority of web hosting — WordPress, most web apps, almost anything PHP or Node — runs on Linux, where the equivalent conversation is live kernel patching (kpatch, KernelCare, Ksplice) rather than Windows hotpatching. Linux hosts have offered rebootless kernel patching for years.

Hotpatching becomes a real decision factor when you genuinely need Windows: ASP.NET, classic .NET Framework apps, MSSQL on the same box, or legacy software with a hard Windows dependency. In those cases, an environment that supports hotpatching can meaningfully cut your downtime.

A few practical things to weigh when picking or auditing a host:

• OS fit: do not pay a Windows licensing premium for a workload that runs perfectly on Linux. Match the OS to the app, not to habit.
• Reboot policy: ask how and when the host reboots for kernel and OS patches, and whether you get notice. Surprise reboots are an uptime problem regardless of OS.
• Control: on a VPS or dedicated server you own the patch schedule; on shared or managed plans the host does. Know which you are buying.
• Privacy and jurisdiction: where the server physically sits affects data-protection law and which courts have reach over it.

If you want strong uptime without Windows licensing overhead, a Linux VPS with live kernel patching is usually the leaner path. LaunchPad Host leans this way — privacy-forward, offshore options, NVMe-backed servers, and crypto-friendly billing — which suits owners who care about uptime, jurisdiction, and value more than running a specific Microsoft stack. Choose Windows hosting when your application requires it, and let hotpatching be a bonus on top.

How should you plan patching around the October 2027 date?

Treat the extension as breathing room, not a reason to stop planning. The date is a deadline for a decision, and the worst outcome is reaching late 2027 with no migration tested and a hard cutover forced on you.

1. Inventory now. List every server actually running Windows Server 2022 Azure Edition and confirm which ones rely on hotpatching for uptime. You cannot plan what you have not counted.
2. Map the baseline windows. Schedule your four quarterly reboots (Jan/Apr/Jul/Oct) as fixed maintenance windows now, so they are routine rather than emergencies.
3. Test patches before they hit production. Hotpatch or not, validate updates in staging. Rebootless patching reduces downtime, not the chance a bad update breaks an app.
4. Keep a rollback path. Snapshots or images before baseline updates so a regression is a restore, not a rebuild.
5. Plan the 2027 move. Decide between upgrading to Windows Server 2025 (and budgeting the hotpatch subscription if you are outside Azure) or migrating the workload to Linux where it fits. Pilot it well before the deadline.

The teams that handle these transitions calmly are the ones that scheduled the work a year out. The ones that panic are the ones who treated an extension as permission to ignore the calendar.