Azure Update Manager is one of the best things Microsoft has added to the Azure platform in years. It is also genuinely insufficient for running a governed patch cycle at scale. Here's the honest difference.
Azure Update Manager is a solid foundation. It is native to Azure, requires no agents on your managed servers, and it is free for Azure VMs. For organisations that have standardised on Azure, it is the obvious starting point for patch management — and for small, simple estates with minimal compliance requirements, it may be all you need.
These are genuine strengths worth acknowledging before talking about the gaps:
No third-party agents, no external infrastructure. Works directly with your Azure subscription and Arc-enabled servers out of the box.
The core AUM tier costs nothing for Azure-hosted virtual machines — a meaningful advantage over agent-based alternatives that charge per endpoint.
Maintenance configurations, dynamic scopes, and schedule-based patching work reliably. The underlying execution mechanism is sound.
On-premises and hybrid servers joined via Azure Arc are treated as first-class citizens alongside Azure VMs — genuinely useful for mixed estates.
AUM was designed as a scheduling and execution engine. It was not designed to manage the full monthly patch cycle — and that distinction matters enormously once your estate grows beyond a handful of servers or a single person who knows exactly what to do and when.
The gaps fall into three patterns, and every Azure patching team hits all three eventually.
AUM gives you the tools. It does not tell you what order to use them in, what to check before you start, or what to do when something goes wrong. Running a patch cycle correctly means knowing the right sequence of assessments, maintenance window creation, pre-patch health checks, compliance reviews, and remediation steps — and knowing what to do when any of them behave unexpectedly.
That knowledge lives in people, not in the platform. The moment the wrong person is unavailable on patch weekend, the process falls apart.
AUM shows you current compliance state. It does not retain it. There is no automatic record of what your estate looked like after last month's patch cycle. If you need to answer "what was compliance in March?" — for an auditor, a manager, or a post-incident review — you either exported a report at the right moment, or you are reconstructing it from Azure activity logs under pressure.
This is where teams often reach for vulnerability scanners to fill the gap. But a vulnerability scanner tells you a patch is missing right now — not whether you were compliant last month. That is answering a different question entirely.
Every additional subscription, client tenant, or managed server multiplies the portal navigation, the configuration updates, and the manual interventions. Exempting a device means finding every maintenance configuration it belongs to across every subscription and removing it one by one. Moving a device between schedules is two manual portal operations per subscription. Answering "which schedule is this device in?" means searching until you find it.
For a single small estate this is manageable. For an MSP managing multiple client tenants — or any organisation that has grown its Azure footprint — the work scales with the estate rather than with the value being delivered.
There is a more fundamental problem underneath all three of the gaps above. AUM-based patching, done well, works. But it works because of the people running it — not because the platform enforces the right behaviour.
"The process works because it is operated by people with deep knowledge of Azure Update Manager and the specific behaviours of the estate. That knowledge is the process."
The risk is not in the tooling. It is in assuming that knowledge transfers automatically when someone leaves, when a team grows, or when a new client environment needs onboarding quickly. Without a structured process, every new person starts from a blank canvas — and every mistake is a learning exercise that happens in production, during a patch window, under time pressure.
The scenarios that catch teams out are not edge cases. They are the ordinary recurring situations that arise every month: a device that should have been temporarily excluded wasn't, because someone forgot to reverse the change. A KB that caused issues three months ago reappeared, because the exclusion was only applied to some configurations. A compliance report was needed for an auditor and no one had thought to export it at the right time.
None of these are AUM failures. They are process failures — and a scheduling engine cannot solve a process problem.
One of the most common attempts to fill AUM's compliance gap is to reach for a vulnerability scanner — a tool that reports which patches are missing on which devices right now. It is useful, but it is answering a different question.
Tells you a patch is missing today. Next month, if that device still has not patched, it becomes a new record — a new finding with a new date. The previous record is closed or superseded.
Ask it "were we compliant in March?" and there is no clean answer. You get what the scanner saw when it last ran — not what your estate looked like after your patch cycle completed.
Vulnerability scanners identify what is exposed. They are not an operational compliance record.
After every patch cycle, OPUS automatically captures a compliance snapshot — a timestamped record of which devices were compliant, which were not, and the compliance percentage across the estate.
Ask it "what was compliance in March?" and you get the answer immediately, regardless of whether anyone remembered to export a report. The record exists because the system created it, not because someone ran a manual process.
Historical compliance is a retrieval operation, not a reconstruction exercise.
When an auditor asks for historical patch compliance data, a team without structured compliance history must reconstruct it from Azure activity logs, maintenance run histories, and whatever manual records exist. This takes hours of stressful work under deadline pressure. With OPUS, it is a 30-second export — the data was captured at the time, automatically, whether anyone thought to ask for it or not.
OPUS does not replace Azure Update Manager. It sits on top of it — using AUM's scheduling engine while adding the governance layer, the structured workflow, the compliance history, and the operational tooling that AUM does not provide. Every patch is still deployed by AUM. OPUS handles everything around it.
OPUS is self-hosted, installs in minutes, and runs a 90-day free trial with full functionality and no device cap. If you are already using Azure Update Manager, you are most of the way there — OPUS just needs a Service Principal and your first tenant configured.
90-day free trial. No payment details required.