Windows Server 2016 End of Support: Upgrade, Arc or ESU?

Status as of October 25, 2026

You have about fifteen weeks. On 12 January 2027, Windows Server 2016 leaves extended support, and the monthly cumulative updates stop arriving on anything that has not been upgraded, migrated, or enrolled in a paid Extended Security Updates programme. If your estate still runs a few hundred 2016 hosts, the planning decision needs to be made this month — fifteen weeks is one inventory pass, one procurement cycle, and not much slack beyond that.

Windows Server 2016 end of support is a budgeting problem wrapped in a patching deadline. The technical options are well documented. What is rarely documented is how to choose between them when you have mixed workloads, a domain controller you are afraid to touch, and three line-of-business apps whose vendors have gone quiet. This framework gives you the criteria, the cost shapes, and the per-workload decision rules.

---

Corrections

Correction 2026-10-24: two statements in the original version of this article were wrong and have been fixed in the text below.

• SPLA licensing. The original said the Services Provider License Agreement (SPLA) is "explicitly not available" for Windows Server 2016 ESU. That was incorrect. Microsoft's Azure Arc ESU preparation guide states that if your Windows Server 2016 machines are licensed through SPLA or with a Server Subscription, Software Assurance isn't required to purchase ESUs. If you run on a service provider licence, confirm the purchase route with your provider rather than assuming you are excluded.
• Mainstream support end date. The original gave 12 January 2022 as the end of mainstream support. Microsoft's Windows Server 2016 lifecycle page lists it as 11 January 2022 (Microsoft shows support dates in Pacific Time). The end of extended support is unchanged at 12 January 2027.

---

What does Windows Server 2016 end of support actually mean?

Windows Server 2016 end of support is the date — 12 January 2027 — after which Microsoft ships no further security updates, bug fixes, or technical support for the product unless you purchase Extended Security Updates. The OS keeps running. It simply stops receiving fixes for newly discovered vulnerabilities, which breaks most compliance baselines immediately.

Three consequences follow, and they arrive on different timelines:

• Day one (13 January 2027): no new CVE patches. Your vulnerability scanner starts accumulating permanent findings.
• Within one audit cycle: PCI DSS requirement 6.3.3, CIS benchmarks, and most cyber-insurance questionnaires treat unsupported OS as a control failure. Expect a finding, not a warning.
• Within 12–24 months: third-party agents start dropping support. Antivirus, backup agents, and monitoring agents follow the OS lifecycle, and once they stop certifying 2016, you lose the compensating controls you were relying on.

Mainstream support for 2016 ended on 11 January 2022, so you have already been on security-only updates for nearly five years. Microsoft's Windows Server lifecycle page is the authoritative date source — bookmark it rather than trusting a vendor blog, because the Server 2016 and Server 2019 dates differ by two years (Server 2019 extended support ends January 2029) and get conflated constantly.

Upgrade, rehost or ESU: which option fits each workload?

Planning for Windows Server 2016 end of support means choosing where to spend a fixed remediation budget across four options, each of which trades money for time differently:

The trap is treating these as mutually exclusive across the whole estate. They are per-workload decisions, and the split below is illustrative only — model your own numbers from the inventory, not these percentages: a 200-server estate with mixed workloads might land somewhere near half in-place upgraded, a quarter migrated to fresh builds, some rehosted to Azure, and a smaller remainder on ESU because something genuinely cannot move yet.

How to inventory what you actually have

You cannot decide per workload until you know the build number, the roles, the hardware generation, and whether the host is even reachable. Start with a domain-wide sweep rather than a CMDB query — CMDBs lie about decommissioned hosts.

# Enumerate every Windows Server 2016 computer object still enabled in AD
Import-Module ActiveDirectory

Get-ADComputer -Filter {
    OperatingSystem -like "*Server 2016*" -and Enabled -eq $true
} -Properties OperatingSystem, OperatingSystemVersion, LastLogonDate, DNSHostName |
    Select-Object Name, DNSHostName, OperatingSystem,
                  OperatingSystemVersion, LastLogonDate |
    Sort-Object LastLogonDate -Descending |
    Export-Csv .\ws2016-live-inventory.csv -NoTypeInformation

LastLogonDate is an approximate, replicated timestamp, so use it to prioritize review—not to exclude hosts from inventory or delete computer objects. Dormant or isolated servers may not log on during the observation window and can still have dependencies. Verify ownership and dependencies with the data owner, then follow your normal backup and change-approval process; quarantine candidates under a documented rollback plan and monitor them before any deletion.

Next, classify by what the host actually does, because roles drive upgrade risk far more than the application inventory does:

# Run against the live list; collects roles, edition, and core count
$servers = Import-Csv .\ws2016-live-inventory.csv

$report = foreach ($s in $servers) {
    try {
        Invoke-Command -ComputerName $s.DNSHostName -ErrorAction Stop -ScriptBlock {
            $os  = Get-CimInstance Win32_OperatingSystem
            $cs  = Get-CimInstance Win32_ComputerSystem
            $cpu = Get-CimInstance Win32_Processor
            $roles = (Get-WindowsFeature |
                      Where-Object InstallState -eq 'Installed' |
                      Where-Object Name -match '^(AD-Domain-Services|DNS|DHCP|Web-Server|FS-FileServer|Hyper-V|Print-Server|ADFS-Federation)$' |
                      Select-Object -ExpandProperty Name) -join ';'

            [pscustomobject]@{
                Host          = $env:COMPUTERNAME
                Edition       = $os.Caption
                Build         = $os.BuildNumber
                Model         = $cs.Model
                GuestVCPUs    = if ($cs.Model -match 'Virtual|VMware|KVM|HVM domU') {
                                    ($cpu | Measure-Object NumberOfLogicalProcessors -Sum).Sum
                                } else { $null }
                MemoryGB      = [math]::Round($cs.TotalPhysicalMemory / 1GB, 0)
                Roles         = $roles
                Virtual       = [bool]($cs.Model -match 'Virtual|VMware|KVM|HVM domU')
            }
        }
    } catch {
        [pscustomobject]@{
            Host = $s.Name; Edition = 'UNREACHABLE'; Build = ''
            Model = ''; GuestVCPUs = $null; MemoryGB = 0; Roles = ''; Virtual = $false
        }
    }
}

$report | Export-Csv .\ws2016-classified.csv -NoTypeInformation
$report | Group-Object { $_.Roles -split ';' | Select-Object -First 1 } |
    Select-Object Name, Count

GuestVCPUs records the logical processors exposed to a virtual machine; it is not the physical-core count of the hypervisor. For physical-core licensing, obtain each host's physical core count from your hypervisor or hardware inventory and reconcile it with the VM inventory. Virtual helps identify whether a side-by-side migration is cheap (snapshot and clone) or expensive (procure hardware). Note that HypervisorPresent is also True on a physical Hyper-V host, so it's deliberately left out of the Virtual match here — the model-string match above can still miss some virtualisation platforms, so cross-check anything flagged as a Hyper-V host (via the Roles column) by hand rather than trusting the automated flag alone.

How to map each Server 2016 workload to a path

Here is the decision flow, stated as rules before the diagram, because the rules are what you will paste into a runbook:

1. Start with the classified server record.
2. If the host runs an app whose vendor does not support Server 2019/2022/2025 → evaluate ESU.
3. If the app is supported but the host hardware is out of warranty → side-by-side migrate to new hardware or Azure.
4. If hardware is supported and the app is supported → in-place upgrade.
5. If the role is a domain controller → prefer build-new, promote, demote the old; in-place upgrade is technically supported but not Microsoft's recommended path for DCs.
6. If the workload is a candidate for rehosting (web tier, stateless app, file server) → Azure IaaS, claiming free ESU.
7. If the host is unreachable or has no identified owner → investigation candidate, not a retirement decision. Validate dependencies and data ownership, and obtain backup and normal change approval before any controlled quarantine; monitor under an approved rollback plan, then decommission only after the responsible owner signs off.

Rule 5 is the most commonly violated in the other direction — teams in-place upgrade a DC because it is faster, then discover SYSVOL replication or FSMO issues mid-change. Building a new DC, letting replication settle, transferring FSMO roles, and demoting cleanly remains the safer default even though in-place is supported.

Can you upgrade Windows Server 2016 directly to 2025?

Yes. Microsoft's supported in-place upgrade paths show Windows Server 2016 as a direct, single-hop source for 2019, 2022, and 2025 — all three are supported in one operation from installation media. The direct 2016 → 2025 path exists because Windows Server 2025 allows nonclustered in-place upgrades from up to four versions back (2012 R2 and later can go straight to 2025); for 2019/2022 targets, the older two-versions-back limit applies instead, and 2016 meets that limit comfortably for both.

That gives three practical single-hop routes, picked by target lifecycle rather than by hop count:

• 2016 → 2022. Supported. Server 2022 extended support runs to October 2031 — about five more years from this article's publish date.
• 2016 → 2019. Supported, but 2019 is the oldest remaining option and buys the least runway; use it only as a stopgap on hardware or app stacks not yet certified for 2022/2025.
• 2016 → 2025. Supported directly, no intermediate hop required. Server 2025 extended support runs to November 2034, and it's the only one of the three with hotpatching via Azure Arc, GPU partitioning, and current SMB over QUIC support (SMB over QUIC server is available on all Server 2025 editions; on Server 2022 it was limited to Azure Edition).

Pick based on how long you want the next OS to live, not on a hop-count penalty — there isn't one here. Most estates without a named 2025 dependency still land on 2022 for ecosystem maturity, but 2025 is a legitimate single-step target if you want the longer runway now.

Before any upgrade, run the compatibility pass and capture a comparison baseline:

# Pre-upgrade gate: run on the 2016 host, from the mounted target-OS media
$media = 'D:'   # mounted installation media for the target version

New-Item -Path C:\upgrade -ItemType Directory -Force | Out-Null

# 1. Capture current state as a comparison baseline (NOT a rollback mechanism —
#    an in-place upgrade cannot be undone; take a VM checkpoint or verified
#    backup separately before proceeding)
$pre = @{
    Features = (Get-WindowsFeature | Where-Object InstallState -eq 'Installed').Name
    Services = (Get-Service | Where-Object Status -eq 'Running').Name
    Shares   = (Get-SmbShare | Where-Object Name -notmatch '\$$').Name
}
$pre | ConvertTo-Json -Depth 3 | Set-Content C:\upgrade\pre-state.json

# 2. Compatibility scan only — makes no changes. -Wait -PassThru so the exit
#    code is captured instead of discarded.
$proc = Start-Process -FilePath "$media\setup.exe" -Wait -PassThru -ArgumentList @(
    '/auto', 'upgrade',
    '/dynamicupdate', 'disable',
    '/compat', 'scanonly',
    '/eula', 'accept'
)
$exitHex = '0x{0:X}' -f $proc.ExitCode
Write-Host "Compat scan exit code: $exitHex"
# 0xC1900210 = MOSETUP_E_COMPAT_SCANONLY, no compatibility issues found

# 3. Read the result from the Panther log under the downloaded upgrade media
#    tree (not $env:SystemRoot\Panther for a scan-only pass)
Get-Content 'C:\$WINDOWS.~BT\Sources\Panther\setupact.log' -Tail 40 |
    Select-String -Pattern 'CompatScan|BlockingIssue|MigXml'

Store pre-state.json off-box and take a verified backup or hypervisor checkpoint before you run the real upgrade — the JSON is a diff baseline for catching a missing share or a service that failed to re-register post-upgrade, not a way to undo the upgrade itself. In-place upgrades are one-way; if it goes wrong, you restore from the backup or checkpoint, not from this file.

After the upgrade, diff the three collections — a missing share or a service that failed to re-register is one of the most common post-upgrade incidents, and it is invisible until a user complains on Monday.

Azure Arc ESU vs traditional ESU: which should you buy?

Microsoft has published an Extended Security Updates programme specifically for Windows Server 2016. Per the Azure Arc ESU preparation guide: Windows Server 2016 reaches end of support on 12 January 2027, and ESU provides Critical and Important security updates for up to three years — through 2030. You can configure Windows Server 2016 ESU enrolment in the Azure portal starting 3 August 2026, and billing for Arc-enabled ESU begins 13 January 2027. Both Standard and Datacenter editions are supported; purchasing ESUs normally requires Software Assurance through a Volume Licensing programme (EA, EAS, EES, SCE or Open Value), but machines licensed through the Services Provider License Agreement (SPLA) or a Server Subscription do not need Software Assurance to buy ESUs — the same rule Microsoft applies to the 2012/2012 R2 programme.

ESU for Server 2016 is sold two ways:

Volume Licensing ESU. The classic route: you must have active Software Assurance through a Volume Licensing programme (EA, EAS, EES, SCE, or Open Value) or an equivalent Server Subscription, then activate a Multiple Activation Key on each applicable server. This is a per-core, up-front, annual commitment — Microsoft has not published a per-core dollar figure for Windows Server 2016 ESU on its public documentation as of this writing, so treat any specific price you see from a reseller as a quote to verify, not a published rate. Check the ESU overview page and your Microsoft account team for current pricing.

Arc-enabled ESU. Connects each server to Azure via the Connected Machine agent (version 1.62 or higher for Windows Server 2016) and bills ESU as a monthly Azure meter — no upfront charge, no key activation, cancellable mid-year, and drawn down against an existing Microsoft Azure Consumption Commitment if you have one. Software Assurance is still required for on-premises workloads enrolled this way. For an estate that is actively migrating, the ability to stop paying for a host the month it's decommissioned is the practical advantage over committing to a full year of Volume Licensing ESU up front.

Microsoft's documentation does not publish a specific minimum core count for Windows Server 2016 ESU enrolment (physical or virtual) on the pages reviewed for this article; the general Windows Server per-core licensing model requires a 16-core minimum per physical server (sold in 2-core packs), and ESU draws on the same per-core counting, but confirm the exact enrolment minimum in the Azure portal or with your licensing reseller at purchase time rather than assuming a number here.

Onboarding a single host to Arc, as a pilot. Install the agent first — downloaded from aka.ms/AzureConnectedMachineAgent — and make sure the Microsoft.HybridCompute, Microsoft.GuestConfiguration, and Microsoft.HybridConnectivity resource providers are registered on the target subscription, and that the host has outbound HTTPS (443) reachability to the Arc endpoints before you run azcmagent connect:

# Cloud Shell or local Azure CLI: register providers and create the resource group
az extension add --name connectedmachine

az provider register --namespace Microsoft.HybridCompute
az provider register --namespace Microsoft.GuestConfiguration
az provider register --namespace Microsoft.HybridConnectivity

RG="rg-arc-esu-prod"
LOC="westeurope"

az group create --name "$RG" --location "$LOC"

az connectedmachine list \
  --resource-group "$RG" \
  --query "[].{name:name, os:osName, version:osVersion, status:status}" \
  --output table

# On the Windows Server 2016 host, after downloading AzureConnectedMachineAgent.msi
# from https://aka.ms/AzureConnectedMachineAgent — -Wait is required, msiexec
# otherwise returns immediately and the connect step below races an unfinished install
Start-Process msiexec.exe -Wait -ArgumentList '/i AzureConnectedMachineAgent.msi /l*v C:\arc-install.log /qn'

# Without service-principal arguments, azcmagent connect normally opens a local
# browser for interactive sign-in. Add --use-device-code if no browser is available.
# For at-scale onboarding, distribute service-principal scripts through GPO or
# Configuration Manager; Azure Policy guest configuration manages machines only
# after they have been onboarded to Azure Arc.
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect `
    --resource-group "rg-arc-esu-prod" `
    --tenant-id      "<tenant-guid>" `
    --location       "westeurope" `
    --subscription-id "<subscription-guid>" `
    --cloud          "AzureCloud"

# Verify the agent reports Connected before assuming ESU eligibility
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" show

Once a server shows Connected, the ESU licence itself is a separate step: create a Windows Server ESU licence resource in the Azure portal (Azure Arc > Extended Security Updates) and link it to the machines. Connectivity alone does not start billing or coverage; the licence link does.

Run the Arc onboarding for your ESU candidates in parallel with inventory, well before January 2027 — connectivity is free, and you only pay once you link an ESU licence resource. Onboarding early means your fallback at the deadline is a portal toggle rather than a procurement cycle.

The Azure IaaS shortcut

If a workload is going to Azure anyway, ESU comes free. Server 2016 VMs running in Azure, or on Azure Local (formerly Azure Stack HCI), receive Extended Security Updates at no additional cost for the ESU period — Microsoft's documentation lists Azure Dedicated Host, Azure VMware Solution, Nutanix Cloud Clusters on Azure, Azure Local, and Azure Stack Hub/Edge as also qualifying, some with extra configuration. That changes the arithmetic on rehosting: compare the cost of on-premises ESU (escalating Volume Licensing fees, or the Arc monthly meter) plus hardware depreciation against Azure compute with Reserved Instances and Azure Hybrid Benefit applied. For servers already approaching a hardware refresh, Azure frequently wins outright.

How much does Windows Server 2016 ESU cost vs upgrading?

Take 40 physical Server 2016 hosts. Assuming ESU follows the base licensing floor of 16 cores per physical server (confirm at purchase), even a fleet of modest 8-core boxes would bill at the 16-core floor — 40 × 16 = 640 billable physical cores of ESU exposure, not 320. For virtual machines, collect the guest vCPU count for virtual-core licensing; do not substitute that count for the hypervisor's physical cores where physical-core licensing applies.

The table below is illustrative only: Microsoft has not published a specific per-core ESU price for Windows Server 2016, so these are relative shapes built on the assumption that later ESU years cost the same as or more than year one, not sourced dollar figures. Validate against your own Volume Licensing quote or the Arc pay-as-you-go meter before budgeting from it.

Treat ESU as a bridge for the servers you genuinely cannot move, not as a strategy — the per-core floor and non-decreasing year-over-year cost make it typically the most expensive per-server-year option, even without a confirmed 2016 number yet.

Pitfalls that derail Server 2016 remediation

Forgetting the SQL Server underneath. SQL Server 2016 reached end of support on 14 July 2026 — before this article was published. If a 2016 host runs SQL 2016, you have two expired products on one box, two ESU bills, and an upgrade order that matters: SQL first or OS first depending on whether the SQL version is supported on the target OS. Check the SQL Server 2016 lifecycle before sequencing.

Assuming ESU covers everything. ESU delivers Critical and Important security updates only. No feature updates, no non-security bug fixes, and no technical support unless you hold a separate active support agreement. A functional regression under ESU has no fix path, and once ESU ends — 2030 for Server 2016 — updates stop entirely; there is no further grace period to plan around.

Over-committing on year-one ESU. Volume Licensing ESU is a full-year commitment. Consider Arc-enabled ESU if there is any chance you will migrate a given host mid-year — the monthly meter stops when the host leaves.

Skipping the driver and firmware pass. An in-place upgrade on hardware with 2016-era storage or NIC drivers is a classic source of a non-booting post-upgrade host. Update firmware and vendor drivers before launching setup, not after.

Ignoring the licence edition trap. Standard-to-Datacenter upgrades work; Datacenter-to-Standard does not. Evaluation builds cannot be upgraded in place at all — they must be converted to retail first with DISM /Set-Edition, and a domain controller running an evaluation build can't be converted in place at all (build a new retail DC and demote the evaluation one instead).

Treating print servers and ADFS as ordinary workloads. Both carry migration-specific tooling (Printer Migration Wizard, ADFS configuration export) and both break in subtle ways under in-place upgrade. Build new, migrate configuration, decommission.

Underestimating the DC path. Before introducing a newer DC, confirm SYSVOL replication is already on DFSR, not the legacy File Replication Service — run dfsrmig /getglobalstate and don't proceed with a Server 2019 or later DC until it reports Eliminated. Forest/domain functional level also gates the install: Server 2016 DCs need at least a Windows Server 2003 forest functional level. Server 2019 and 2022 DCs need at least the Windows Server 2008 functional level, and a Server 2025 DC needs at least the Windows Server 2016 functional level. Server 2025 adds a new Windows Server 2025 functional level, which you can only raise to once every DC runs 2025.

Why do Server 2016 remediation projects stall?

Most Windows Server 2016 end of support projects stall on the step with the least glamour: inventory. Teams that skip a live reachability sweep and instead trust the CMDB discover mid-project that their server count, role mix, and core totals were all wrong, and the budget they got approved doesn't match the fleet they actually have to move. Written vendor-support answers are the second-most-skipped step — a sales call isn't evidence for an ESU justification, but a dated email is.

What to do before 12 January 2027

Run Arc onboarding for likely-ESU candidates in parallel with inventory from week one — don't wait for the full classification pass to finish before starting connectivity work, since Arc connectivity itself is free and reversible.

1. Weeks 1–2: run the inventory and classification scripts. In parallel, start onboarding your likely-ESU candidates (vendor-blocked apps, apps with no 2022/2025 certification yet) to Azure Arc — connectivity only, no licence linked yet. Produce a classified CSV with owner, role, hardware generation, guest vCPUs for VMs, and physical core counts from the hypervisor or hardware inventory. Treat stale AD objects as review candidates: validate ownership and dependencies, follow backup and change-approval procedures, then quarantine and monitor under a rollback plan before deletion.
2. Weeks 3–4: send the app vendor support matrix question in writing to every third-party vendor on the list. Written answers, not sales calls — the replies become your ESU justification. Continue Arc onboarding for newly identified ESU candidates as classification completes.
3. Weeks 5–7: pilot one in-place upgrade per role class in a non-production copy. Capture the pre-state JSON, take a verified backup or checkpoint, upgrade, diff. Document the actual outage duration against your own test, not an assumption.
4. Weeks 8–10: build the costed plan with per-workload decisions, and get the licence and Azure budget approved before the deadline, not after it.
5. Weeks 11–14: for every host confirmed for ESU, create and link the ESU licence resource well ahead of the deadline — don't wait until December. Confirm azcmagent show reports Connected and the licence shows linked on every host.

The deadline is fixed and the options narrow as it approaches. Teams that start the inventory and Arc onboarding this month spend their 2026 budget on upgrades and a bridge for the rest. Teams that wait until the new year spend it on ESU instead, and still have the same migration backlog to fund afterward.

Related Articles

• Retirement Debt Comes Due: Azure VPN Client for Linux, AVD Classic, Graph Toolkit and Project Online
• Reserved Instances vs Savings Plans vs Spot VMs: An Azure Cost Optimization Comparison
• Secure Boot Certificates and Memory Integrity by Default in Windows