TL;DR: Don't export your WSUS console and just call it a day. Document why each approval, deadline, and exception exists, then map only the controls that still earn their keep. Confirm which service each device actually scans, pilot on a representative ring, and delete old GPOs only after the results match your expectations.
Your WSUS server has probably outlived a couple of managers and at least one "temporary" exception that nobody can quite explain. Approvals, declined updates, and GPOs all seem to pile up until no one remembers why finance laptops skip driver updates. Microsoft's WSUS deprecation means that no new features are coming, and a WSUS migration is the perfect excuse to clean house. This guide was specifically created to cover how to migrate WSUS approvals and update policies by separating the controls that you need from the configuration that you inherited.
Which WSUS approvals and policies should you inventory?
Start with what devices actually experience, not what the console history says. Approval history shows what someone clicked, but active policy shows what endpoints actually do today.
Inventory these:
Products and classifications: What WSUS syncs, and what nobody approves anyway
Targeting groups: Computer groups and whether membership comes from the console or client-side targeting
Deadlines and auto-approval rules: What gets approved automatically and how fast it must install
Deferrals and restarts: Scheduled install times, active hours, and restart deadlines set by GPO
Exclusions: Declined updates, unapproved KBs, and devices pulled out of patching
Source settings: The intranet update service location and any per-class source settings
For every exception, record why it exists, who owns it, and whether it’s still important. An exclusion with no owner and no ticket is a candidate for retirement, not migration. If you're working out how to migrate WSUS approvals and update policies for several different sites, run this inventory per site, since autonomous downstream servers manage their own approvals and collect their own quirks..
How do you translate approvals into a new workflow?
Build a mapping table for each behavior that you're keeping, its replacement control, and any gaps in between. This is the heart of how to migrate WSUS approvals and update policies, and it keeps 2017's mistakes out of your shiny new console.
WSUS behavior | Destination control | Watch out for |
|---|---|---|
Security and critical approvals | Scheduled deployment to a target group | Auto-install or review first? |
Computer groups | Device groups built from current criteria | Stale membership |
Install deadlines | Deployment schedule plus restart deadlines in Windows Update client policies | Settings that fight each other |
Declined or held KBs | Documented exclusion with an owner and review date | No direct equivalent in some tools |
Driver approvals | Separate small-batch driver workflow | Mixed makes and models |
Intranet service location | Per-class source setting; retain the WSUS server setting while any update class still uses WSUS | Devices still pointed at WSUS |
Then check where each device actually scans. On Windows 10, version 2004 and later and Windows 11, Microsoft's scan source policy sends feature, quality, driver, and other updates to WSUS or Windows Update separately. Run gpresult /h report.html on pilot devices to review applied Group Policy settings, then check Windows Update logs to confirm the source used for scans. If Intune also manages those devices, check the MDM diagnostic report too, since gpresult only shows Group Policy. Then trigger a scan and confirm it hits the source you intended.
Give each update type one owner per device group. If Intune, Configuration Manager, and a GPO all push Windows Update policies at the same machine, you'll spend all of Patch Tuesday doing forensics. Sort out who owns update policy first, and remember that Configuration Manager's software update point still requires WSUS. For an implementation example, see how to replace WSUS with PDQ.
How do you pilot and retire the old policy safely?
The pilot is where your plan for how to migrate WSUS approvals and update policies proves itself. Pick a ring that mirrors your fleet, such as remote laptops, that cranky line-of-business app, a server or two, and a device with a known exception.
Compare offered vs. installed: Match what the new tool offers against what WSUS approved, then confirm what installed.
Watch restarts: Confirm deadlines and active hours behave as documented.
Set rollback criteria up front: Define triggers, like a broken app or wrong scan target, and test how to restore the previous update configuration. Plan recovery from installed updates separately; relinking a GPO does not uninstall an update.
Expand gradually: Move through deployment rings only after each ring matches expectations.
Retire superseded policy last: Unlink old GPOs, wait a full patch cycle, then delete them. Leave Windows Update services alone, since replacement tools typically rely on the Windows Update Agent for scanning.
Where does PDQ fit?
PDQ can be the deployment and visibility layer for selected Windows update workflows, but it doesn't import WSUS approval state or replace every WSUS role. In PDQ’s cloud platform, the Windows updates tab shows missing KBs per device and installs applicable ones. PDQ’s PSWindowsUpdate packages add audit-only and targeted workflows that pull content from Microsoft. They temporarily bypass WSUS and restore its settings afterward, so verify the device’s ongoing scan source separately.
Do you need self-hosted management? PDQ Deploy & Inventory run on-prem and support air-gapped networks. The PSWindowsUpdate packages are the exception: They download directly from Microsoft, so they won’t work on disconnected devices. Keep WSUS or another validated offline Windows update workflow in place for disconnected devices.
Are you ready to test your plan for how to migrate WSUS approvals and update policies? Start a free trial of PDQ and run it against your pilot ring.
