Cloudek.Request a service session

Windows Server

Windows Server 2016 WSUS: Migrate or Upgrade the Update Server

Windows Server 2016 WSUS: upgrade in place or migrate SUSDB and content, change the server identity, repoint clients, and know what deprecation means.

The Windows Server Update Services (WSUS) server is the machine that keeps every other machine patched, which makes it awkward to be the one left behind. If your WSUS server runs Windows Server 2016, you have two decisions: how to move it, and whether to keep WSUS at all. This guide covers both, with the steps from Microsoft's migration checklist, what has changed since that checklist was written, the rollback point, and the mistakes that leave clients unpatched without anyone noticing. Sources checked 6 November 2026 against Microsoft Learn, Microsoft Lifecycle and the Windows IT Pro blog; they are listed at the end.

Verdict

Verdict: Either.

Microsoft's role matrix supports both in-place upgrade and migration for WSUS; choose by the layout of your database and content store, and note that Microsoft has deprecated WSUS while continuing to support it.

Deprecated does not mean removed. Microsoft says deprecated features continue to work and are fully supported until removed, that it has no current plans to remove WSUS from in-market versions of Windows Server including Windows Server 2025, and that it will continue to publish updates through the WSUS channel. It also names alternatives for new designs: Windows Autopatch and Microsoft Intune for clients, and Azure Update Manager for servers.

Who this is for and what changes on the end-of-support date

This is for anyone running the WSUS role on Windows Server 2016, with its database in Windows Internal Database (WID) or in SQL Server, including downstream servers that synchronise from it and the Configuration Manager sites that sometimes use it.

Microsoft Lifecycle lists Windows Server 2016 under the Fixed Lifecycle Policy. The Lifecycle table shows the extended support end as 1/13/2027 6:59:59 AM, while Microsoft's extended security updates page names 12 January 2027. Plan to finish before 12 January 2027.

Clients keep patching on the day, so the risk is quiet: the server that approves and distributes updates to your estate loses its own security updates unless you buy Extended Security Updates. On ESU, Microsoft's Azure Arc documentation says Windows Server 2016 reaches end of support on January 12, 2027, and that Extended Security Updates provide Critical and Important security updates for up to three years, through 2030, without new features, customer-requested nonsecurity hotfixes or design change requests. Arc-enabled ESU can be configured in the Azure portal from August 3, 2026, and its billing begins January 13, 2027. Standard and Datacenter editions are supported; physical-core licences need at least 16 cores per machine, and virtual-core licences need at least 8 per VM and use Standard. You must attest to Software Assurance or an equivalent server subscription, or license through SPLA. The pages I read show no price, so get a quote. Microsoft describes ESU generally as a last resort paid option and a temporary bridge, so treat it as a way to finish a migration, not as the plan.

One more fact to plan around: Microsoft's list of deprecated features says WID, which WSUS and several other roles use, will be removed from Windows in a future release, and suggests considering a free or full version of SQL Server for those roles. If you are rebuilding anyway, put the new database in SQL Server.

Decision table

OptionWhat Microsoft documentsFit for WSUS
Stay and buy ESUAzure Arc ESU: Critical and Important updates for up to three years, through 2030, billed from 13 January 2027; needs Software Assurance or an equivalent subscriptionA temporary bridge, not a plan; no price is published on those pages, so get a quote
In-place upgradeThe role matrix lists WSUS as upgradeable in placeSimple if the content drive and database are healthy and you accept a one-way change
Side-by-side migrationMicrosoft's archived migration checklist: move binaries, security groups and the SUSDB database, change the server identity, repoint clientsBest for a clean database, new storage or a move from WID to SQL Server
Move to Azure or SaaSMicrosoft recommends Azure Update Manager for server updates and Windows Autopatch or Intune for clientsA redesign, not a migration; decide it before you build another WSUS

A caution on sources: Microsoft's step-by-step WSUS migration guide that I found is archived and written for Windows Server 2012 and 2012 R2. The steps still describe the moving parts, but check each against your versions and test before cutover.

Steps, with the rollback point

  1. Inventory. On the WSUS server run Get-WsusServer | Select Name, PortNumber, and in the console record products, classifications, languages, computer groups, automatic approval rules, downstream servers and the content location. Find the database location with the SqlServerName value under HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup. Note the Group Policy objects that point clients at the server.
  2. Decide the content store. Microsoft's archived guide says migrating update binaries is unnecessary if updates are stored on Microsoft Update (clients download from Microsoft), and otherwise to copy the WSUS content folder with Robocopy or similar. Another common approach is to let a new server download its own content, which I did not find described on a Microsoft page.
  3. Build the new server. Install a supported Windows Server and the WSUS role with Install-WindowsFeature UpdateServices-Services, UpdateServices-WidDB -IncludeManagementTools (or UpdateServices-DB instead of UpdateServices-WidDB for SQL Server), and run post-installation with wsusutil postinstall (using the SQL and content parameters you chose; omit the SQL parameter for WID). Do not synchronise yet if you will restore the database.
  4. Migrate security groups. Recreate the WSUS Administrators and WSUS Reporters local group members by hand or with Windows Server Migration Tools, as the guide describes.
  5. Back up the database. Take a copy-only full backup of SUSDB from the old server using SQL Server Management Studio (for WID connect through \\.\pipe\MICROSOFT##WID\tsql\query). Rollback point: the old server is untouched, and Microsoft's guide says the migration makes no changes to it.
  6. Restore the database. Drop the empty SUSDB on the new server, restore your backup, then run wsusutil postinstall. Microsoft notes you may see a schema-verification error during restore that the guide says to disregard, and orphaned database users to clean up.
  7. Change the server identity. On the new server, give it a new server ID with the script in Microsoft's guide ($config.ServerId = [System.Guid]::NewGuid() followed by $config.Save()), then run wsusutil postinstall again to generate a new encryption key. Microsoft says this keeps WSUS-managed clients from being affected, because two servers must not share an identity.
  8. Repoint downstream servers. In each downstream server's Options, choose Update Source and Proxy Server and synchronise from the new server, and confirm in the upstream console that the last synchronisation date has moved.
  9. Repoint clients. Change the Group Policy setting "Specify intranet Microsoft update service location" to the new server's name. Force detection: the archived guide uses wuauclt /resetauthorization /detectnow, but Microsoft's removed-features list says wuauclt.exe /detectnow was removed in Windows Server 2016 and gives a PowerShell replacement ((New-Object -ComObject "Microsoft.Update.AutoUpdate").DetectNow()).
  10. Validate. In the new console check that computers appear with a fresh last-contact time, that approvals and groups are present, and run the computer tabular status report. Wait a week, then check the old server for clients whose last status report is newer than the cutover.
  11. Retire. Once no client contacts the old server, uninstall the role and decommission it.

Mistakes that cause outages

  • Two servers with one identity. Skipping the server ID change breaks communication with clients when either server changes.
  • Content store on a full or wrong drive. Updates download for hours, then the disk fills.
  • Forgetting the downstream servers. They keep synchronising from a server you have turned off.
  • Group Policy left on the old name. Clients quietly stop reporting; use the old console's last status report to find them.
  • Restoring into a mismatched database. The restore needs matching SQL versions and the post-install step afterwards.
  • Using a removed command for detection. wuauclt /detectnow no longer works on Windows Server 2016 and later.
  • Losing approvals. If you build fresh instead of restoring SUSDB, you lose computer groups, approvals and settings.
  • Assuming deprecation means unsupported. It does not, but plan the next design now.

Checklist

  • WSUS products, classifications, groups, approvals, downstream servers and GPOs recorded
  • Content store decision made; database choice (SQL Server or WID) made
  • New server built; groups migrated; SUSDB backed up and restored
  • Server identity changed; post-install run
  • Downstream servers and clients repointed; detection forced
  • Reports checked a week later; old server shows no clients
  • Old server retired
  • Finish before 12 January 2027

Related tools and reading

See the Windows Server 2016 end-of-support planner for the rest of your roles. If you are moving client management to the cloud, our Microsoft 365 licence audit guide and licence cost calculator help with the licensing side. The full series is in the role-by-role guide.

Sources

Checked 6 November 2026.

General planning information, not a design for your environment. Test the restore and the client cutover with a pilot group first.

🗲 CLOUDEK AUTOMATION WORKBENCH • FREE INFRASTRUCTURE DIAGNOSTIC

A scoped starting point for cloud operations

  • OPERATION TYPE: Read-only Microsoft 365 service-health pilot; Azure inventory is limited to its separately approved resource group.
  • DATA HANDLING: Page-view analytics use fixed page labels and aggregate counts. Pilot OAuth tokens use in-memory MSAL storage and clear on refresh or close. Hosting logs are separate.

Was this helpful?