The word deprecated has done more damage to more patching projects than any technical failure I can name. It arrives in a meeting, everyone hears end of life, and a plan gets built around a deadline that does not exist. WSUS was deprecated in September 2024. It ships in Windows Server 2025, it is supported for production, and its lifecycle runs into the 2030s. So the question of what to do about it has to be argued on its merits rather than settled by the announcement.
What deprecated actually means here
Microsoft defines the word on the page where it does the deprecating, and the definition is narrower than the reaction to it. Deprecation means a feature is no longer in active development and might be removed in a future release. A deprecated component still ships in Windows Server, is supported for production deployments, and continues to receive security and quality updates per the product lifecycle. The WSUS entry itself says only that WSUS is no longer actively developed and that all the existing capabilities and content continue to be available for your deployments.
Read plainly, that is a commitment not to improve it, and nothing else. There is no shutdown date anywhere. The role is in Windows Server 2025, and a Long-Term Servicing Channel release carries five years of mainstream and five of extended support, so the last supported WSUS server on the newest operating system is a mid-2030s proposition. If you want confirmation that Microsoft’s own reversals bite the doomsayers, consider that the plan to remove driver synchronization from WSUS was announced, scheduled for 2025, and then postponed indefinitely after customer feedback. It never happened. Anyone who wrote a migration plan around that date wrote it around a thing that did not occur.
WSUS is draining slowly rather than burning, and the two situations are managed differently.
The distinction matters because it changes who is in charge of the timetable. A burning platform sets your dates for you. A draining one leaves you to set them, which is harder, and which is why so many estates simply never decide.
Cat Snack Jack already runs two patch sources
Before arguing the decision, it is worth establishing that the estate has already made half of it without noticing, because this is almost universally true and almost never in the documentation.
Nine of Cat Snack Jack’s servers are domain-joined and pick up the Group Policy that pins the Windows Update client at the WSUS server. One is not. The Windows Server 2025 machine in Azure was built from a marketplace image, never joined to the domain, and therefore never received that policy. Microsoft’s own statement of the default is that the Windows Update Agent is configured to fetch updates from the Windows Update repository, so that machine has been patching itself straight from Microsoft since the hour it was created, against no approval gate, on no schedule anybody set, reporting to nobody.
Nobody chose that. It is what a server does when no policy reaches it. And it means the question in front of us is not whether to introduce a second patch source into a clean single-source estate. It is whether to keep running two sources by accident or to run them by design and then converge them. Every estate I have looked at that has any cloud footprint at all is in this position, and most of them describe themselves as WSUS shops.
The case for keeping WSUS
I want to make this case properly rather than knock it down, because it is stronger than the migration literature admits and because three of its four legs are load-bearing in real estates.
The first leg is approval. WSUS has a human sign-off step: an update is not installable on your machines until somebody approves it. Update Manager has no equivalent concept anywhere in the product. Its selection controls are classifications, explicit KB inclusion and exclusion, and a maximum publish date, and every one of those is a filter rather than a gate. This is my reading rather than a Microsoft statement, so weigh it as such, but I have not found a way to express per-update sign-off in Update Manager and I do not think one exists. If your change process genuinely requires that a named person approves each update before it can reach production, WSUS holds the only mechanism either product has, and Update Manager scheduling on top of a WSUS source is the design that keeps it.
The second leg is third-party patching, and it is the one that actually keeps WSUS servers alive. Update Manager does not patch third-party software on Windows. Microsoft’s guidance is to import and publish third-party applications and custom updates to WSUS, at which point Update Manager will install what WSUS offers. So the successor product depends on the deprecated product for a category of work many estates bought their patching tooling to do. If you are publishing third-party updates into WSUS today, cutting the source does not move that work somewhere better; it deletes the capability. The honest options are a standalone WSUS fed by a publishing tool, a dedicated third-party patching product, or keeping Configuration Manager if you have it.
The third leg is bandwidth, and it is real but smaller than people assume. Update Manager cannot pre-download; the documentation says so directly. Every machine pulls its cumulative update inside the maintenance window rather than staging it overnight. WSUS, whatever else is wrong with it, downloads once and serves locally. And the obvious mitigation is weaker on servers than on clients: Delivery Optimization requires Windows Server 2019 or later, so the four Windows Server 2016 machines here get none of it at all, and on servers that do support it the default download mode is the peerless one rather than the client default that shares on the local network. Peering on a server estate is something you deliberately turn on, not something you inherit.
The fourth leg is inertia dressed as prudence, and I will name it as such. The GPO works, the console is familiar, the approvals happen on a Wednesday, and nobody has been asked to justify any of it in years. That is not an argument, but it is a reason, and pretending otherwise is how consultants lose rooms.
The case for cutting it
The strongest argument against keeping WSUS is not that it is deprecated. It is that a middle tier you no longer develop is a middle tier that can fail in ways nobody is going to fix elegantly, and that its failures are quiet.
Start with the quiet one, because it is specific to running both products together. Microsoft’s instruction for using WSUS with Update Manager includes a bullet that reads like housekeeping and is not: ensure that updates are approved in WSUS, to prevent the failure of Update Manager deployments. Unpack that. Update Manager can only install what the machine is offered, and the machine is only offered what WSUS has approved. If an approval is missed, the maintenance window opens, the run executes, the run succeeds, and the update you cared about is simply not there. Your compliance view is now reporting on the intersection of two systems, and the failure surfaces as an absence rather than an error. That is the worst failure shape there is, and it is a direct consequence of running the two together.
Then the operational tax, for which there is now a dated, first-party exhibit rather than an anecdote. In July 2026 Microsoft posted a service degradation on the Windows Server release health pages: WSUS sync operations might have issues or time out, caused by a buildup of publishing metadata, with heightened impact from 13 July. The affected platform list runs from Windows Server 2012 to Windows Server 2025, so this was not a legacy-only event. It is marked resolved as of 20 July, and I am not going to overstate a closed incident. What is worth your attention is the shape of the resolution, which came in two parts. A service-side mitigation on 18 July restored things for newly installed or rebuilt WSUS servers. Existing installations were told they could benefit from manual steps to clean up unneeded metadata, in a support article published for the purpose.
The platform fixed itself for the servers nobody has built yet. The one sitting in your comms room got a KB article and an afternoon of work.
That is the tax, precisely stated. Not an outage, not a scandal, and not an argument that WSUS is unreliable. An argument that the burden of keeping a no-longer-developed middle tier healthy has quietly transferred to you, and will keep transferring. Nobody at Microsoft is going to make WSUS better at holding metadata.
Two smaller points finish the case. WSUS drags a surface area behind it that is easy to forget you own: a Group Policy pinning every machine, a database, an IIS site, a content volume, and on most installations the Windows Internal Database, which is itself deprecated and which Microsoft says will be removed from Windows in a future release. And on this estate specifically the WSUS server runs Windows Server 2016, so its own operating system reaches end of support on 12 January 2027. The box has a date on it whether or not the role does.
The ruling
Coexist deliberately, then cut ring by ring, and retire the box last.
The reason that is not a fence-sit is the product’s own architecture. Update Manager honors the update source on the machine and does not publish updates, so coexistence is not a transitional compromise you negotiate. It is the day-one state of every Update Manager deployment on machines that are already pointed at WSUS. You do not have to build it, and you cannot avoid it. What you get to choose is whether you leave it undefined or make it a phase with a beginning and an end.
So the sequence is schedule first, source second, and the two are never changed in the same operation.
Phase one moves the change window into Azure while WSUS remains the content source and keeps approving exactly as it does today. Nothing about where updates come from changes. Rings become maintenance configurations, the reboot decision acquires an owner and a role, reporting moves into Resource Graph, and you find out whether your ring definitions actually describe your estate before any content is at stake. That is the whole of the next article and its build sheet, and it is deliberately a boring phase, because you want your first Update Manager surprise to happen while the familiar system is still underneath.
Phase two repoints the source, one ring at a time, and it is Group Policy work from beginning to end. Update Manager plays no part in it beyond observing the result, which is not my framing but Microsoft’s instruction: to change the patch source, use Windows settings or Group Policy, and do not use Update Manager for this. That article is the flagship of this series because the traps are real and specific, including one that fires on exactly the mix of operating systems in this estate.
Phase three retires the server, once nothing is talking to it.
Naming the exit before you start
A coexistence phase with no stated exit is not a phase. It is the new architecture, and it is the one I find in estates five years later, still running, still costing two systems of maintenance, still described as temporary by people who were not there when it started.
So write the exit down at the beginning. The criterion I use is one full successful patch cycle per ring, verified in Update Manager’s own installation records, before that ring’s source is cut over. Not one machine, not a smoke test: an entire ring going through a real monthly cycle, scheduled by the maintenance configuration, with the results legible afterwards. Then that ring moves, and the next ring stays on WSUS until it has met the same bar.
You should know that this number is mine. I went looking for an authoritative answer to how long to run the two side by side and did not find one, from Microsoft or from anybody else. The published accounts I did find agree on running in parallel and retiring last, and none of them I have read puts a duration on it. So treat one cycle per ring as a defensible floor rather than a documented standard, and if your change board wants two, take two. What matters far more than the number is that the criterion is stated in terms of evidence rather than time. A phase that ends when the rings have proven themselves ends. A phase that ends next quarter does not.
Three things belong in the same decision, so that phase one is not quietly building phase two’s problems.
Keep approving in WSUS, and mean it. Approval discipline during coexistence is more important than it was before, because a missed approval now presents as a clean Update Manager run with something missing from it. If your approvals have drifted towards being rubber-stamped anyway, Microsoft’s own migration guidance suggests auto-approval rules so that Update Manager always has approved content to install, which is an admission worth reading twice: the recommended coexistence posture is one where the approval gate stops gating.
Decide now what happens to third-party patching, because it does not survive the cut by itself. Cutting the source ends third-party patching for that ring on the day it happens, and discovering this after the fact is the sort of thing that gets a migration paused. If the answer is a standalone WSUS kept alive purely as a third-party publishing point, that is a legitimate architecture and it changes what phase three means: you are not retiring WSUS, you are demoting it to one job and deleting the rest.
And keep an eye on the lockdown setting, because it is the coexistence artifact most likely to strand a machine later. Microsoft lists enabling Do not connect to any Windows Update Internet locations as a legitimate step for restricting internet access in a WSUS estate, and plenty of estates have it on. It only does anything while the machine is pointed at an intranet update service. Take away the WSUS pin without taking away that setting, in the same change, and you have a server that can reach neither source. It belongs on the checklist now, while it is a note, rather than during the cutover, when it is an outage.
When the answer is genuinely keep
I would rather give you the conditions than the conclusion, because for some readers the conclusion is different and the worst outcome of this article would be someone starting a migration their estate cannot finish.
Keep WSUS as your content source, with Update Manager scheduling on top of it, if third-party publishing into WSUS is load-bearing and you are not replacing it with something else. Keep it if per-update human approval is a written requirement you cannot renegotiate. Keep it if you patch machines with no route to the internet at all, where a local source is not an optimization but the only mechanism. In every one of those cases you still get most of what this series is about, because the schedule, the rings, the role separation and the reporting are all independent of where the content comes from. You simply stop after phase one, deliberately, and write down why.
What I would not do is keep it by default, or keep it because the alternative was never costed, or keep it because deprecated sounded like a problem for later. Those are the three ways this decision gets made in practice, and none of them is a decision.
Where this goes next
If you have read the Arc series here, you met a shorter version of this argument in [ARC 4], where Update Manager appears as one capability of the Arc management plane and coexistence gets a paragraph. This series is that paragraph taken seriously, and where the two differ, this one is later and more specific.
The decision is made, so the next article builds phase one: maintenance configurations as the change window made into a resource, dynamic scoping that resolves ring membership at run time rather than at authoring time, the tag governance that has to sit underneath it, and the named role that separates deciding when a server reboots from being able to administer it. Its build sheet stands the whole thing up across this estate and runs a first full cycle with WSUS still supplying every byte, which is the cleanest possible proof that the schedule and the source are two different levers.
The cutover itself, phase two, comes later and gets the longest treatment in the series. It is worth knowing in advance that its central technique is to descope rather than to edit: the WSUS Group Policy is left exactly as it is and machines are removed from its scope ring by ring, so that rollback is putting a machine back rather than reversing a change. That is the property that makes cutting the source survivable, and it is the reason the rings have to be right before any of it starts.
Azure Update Manager
‹ Previous: [AUM 1] Azure Update Manager: Patching as an Authority Question
Next: [AUM 3] Rings, Windows, and Who Owns the Reboot ›
