AI Adoption GuideITUpgrade
Upgrade readiness assessor
AI agent cross-references CMDB dependencies, patch history, and vendor compatibility matrices to produce a per-asset upgrade readiness score.
IT processPlanSelectDeployProvisionSupportUpgradeReplaceRetire
By Don, DoneThat’s AI coach · updated
Overview
The upgrade readiness assessor answers one question before you open a change request: is this asset actually ready for the target version, and what evidence supports that call? An AI agent pulls from your CMDB, patch records, and vendor compatibility data, then returns a per-asset readiness score with citations. You get a defensible starting point for CAB review, not a substitute for it.
Most upgrade failures trace back to missing context, not bad execution. A server looks current until you discover it still runs a dependency two major versions behind. A cluster passes a quick version check but sits on a build VMware has flagged as incompatible with your target ESXi release. A Windows host shows green in monitoring while adjacent automation nodes carry open kernel gaps in Red Hat Satellite. The assessor surfaces those gaps before they become rollback stories.
What the agent evaluates
The assessor treats upgrade readiness as a composite of three evidence streams, each with a distinct owner in most enterprises.
CMDB configuration items and dependencies. From ServiceNow or an equivalent CMDB, the agent maps the target CI, its upstream and downstream relationships, and classification metadata (environment, criticality, support group). It does not invent relationships. If the CMDB has no dependency edge, the output leaves that field empty rather than inferring one.
Patch and build history. Patch data comes from your patch management source of record: Microsoft WSUS or Update for Compliance, Red Hat Satellite or equivalent, VMware vSphere lifecycle reports, or consolidated feeds into ServiceNow. The agent compares installed or missing patches against the vendor's stated prerequisites for the target version.
Vendor compatibility matrices. Published support matrices from Microsoft (OS and application interop), VMware (ESXi, vCenter, and guest OS compatibility), and Red Hat (RHEL major/minor support boundaries) define hard gates. The agent flags explicit incompatibilities and version ceilings. It does not downgrade a hard block to a warning.
The output is one readiness score per asset in scope, with line-item citations so a reviewer can trace every contributing factor.
How the readiness score is calculated
Scoring is deterministic given the inputs. The agent does not smooth over gaps to produce a friendlier number.
Each asset receives a score band (ready, conditional, or not ready) derived from weighted checks:
- CMDB completeness. Required fields present: CI name, environment, owner, and at least one verifiable dependency link where your standard mandates it. Missing data reduces confidence but does not fabricate values.
- Patch gap analysis. Open gaps against vendor prerequisites are listed with CVE or KB identifiers where available. A critical prerequisite missing typically caps the score at conditional or not ready, depending on your policy thresholds.
- Compatibility flag. A direct matrix conflict (unsupported guest OS on target hypervisor, RHEL version outside the support window for a dependent middleware version) sets compatibility to fail and forces not ready unless your organization defines a formal exception path.
Conditional scores should name the specific remediation: install a named Microsoft cumulative update, raise RHEL from 8.8 to 8.10, or confirm VMware Tools version on guests before a host upgrade. Vague guidance is treated as a quality defect in the agent output.
What appears in the change record
The assessor is built for auditability. Every score line ties back to a source object a CAB member can open.
| Output field | Typical source | Empty when |
|---|---|---|
| CMDB CI reference | ServiceNow cmdb_ci record | CI not found or out of scope |
| Patch gap | WSUS, Satellite, or ServiceNow patch tables | No patch data feed for that asset |
| Compatibility flag | Vendor matrix lookup | Matrix has no row for that combination |
Empty stays empty. The agent does not backfill patch gaps from assumptions, guess CMDB relationships from naming conventions, or mark compatibility pass when the matrix is silent. Silence in source data is itself a signal: conditional at best, often not ready until someone validates manually.
Attach the assessor output to the change request as structured evidence (JSON or ServiceNow attachment, depending on your integration). Change managers should expect three citation types in the narrative the CAB reads:
- CI cite:
cmdb_ci_server:SRV-PROD-0142with environment and dependency summary. - Patch gap cite:
KB5034441 missing; last scan 2026-02-18 via WSUS. - Compatibility cite:
FAIL: RHEL 8.6 guest not supported on ESXi 8.0 U3 per VMware matrix row X.
If any cite cannot be produced from connected systems, the field remains blank and the overall score reflects incomplete evidence.
CAB workflow and the quality outcome
CAB still approves. The assessor reduces discovery time in the meeting; it does not remove human judgment on risk, timing, or business priority.
Use the score to sort work, not to auto-approve it. Ready assets with full cites can move through standard change faster. Conditional assets need a linked remediation task or a documented risk acceptance. Not ready assets should not reach implementation windows without an exception record.
A practical sequence for change managers:
- Run the assessor against the change scope (single CI, cluster, or batch from a maintenance window list).
- Review empty fields first. Those are your data-quality tickets before CAB, not CAB debate items.
- For conditional items, open companion workflows: patch prioritization by risk to sequence remediation, and pre-flight configuration validator to confirm settings that matrices do not cover.
- Attach scored output to the change. CAB validates cites, discusses blast radius using change impact simulator output where dependencies are non-trivial, and approves or defers.
- After approval, hand off to deployment runbook generation with readiness cites embedded so execution teams see the same evidence operators reviewed.
The quality bar is simple: every non-empty field in the score must be traceable. CAB members should be able to click from cite to source and agree or disagree with the agent's conclusion. Disagreement is fine; missing evidence is not.
Vendor-specific considerations
ServiceNow. Treat the CMDB as the identity anchor. Map assessor scope to cmdb_ci classes your upgrade policy covers (servers, VMs, clusters). If discovery is stale, scores will look artificially ready. Pair assessor runs with a CMDB freshness check on any CI older than your defined threshold.
Microsoft. Windows Server and desktop upgrades depend on cumulative update chains and sometimes .NET or SQL co-requisites. Pull patch state from the same system you use for compliance reporting so CAB sees one truth. Feature-update versus in-place servicing paths may change which KB rows matter; configure the agent with your organization's approved target build, not a generic "latest."
VMware. Host upgrades require checking ESXi build compatibility, vCenter version pairing, and guest VMware Tools levels. A host can be ready while guests are not; score at the granularity CAB expects (often per-cluster with guest roll-up). VMware's matrix is explicit about unsupported combinations; do not override fail flags without a recorded exception.
Red Hat. Major versus minor RHEL moves have different risk profiles. Satellite provides errata and channel data the assessor needs for patch gap cites. Watch for mixed environments where Windows workloads on VMware still depend on RHEL-based automation or identity services; CMDB edges matter here.
When to run it and what to expect
Run the assessor early in change planning, again after remediation, and once more at freeze if your window is long enough for drift. Batch runs across a maintenance scope surface patterns (systematic Tools gaps, recurring KB holes on a subnet) that single-asset review misses.
Expect the first production run to expose integration gaps: missing patch feeds, sparse CMDB relationships, or compatibility matrices not loaded for niche SKUs. That is normal. Fix the feeds, re-run, and treat improved cite coverage as the success metric before you chase higher ready percentages.
The upgrade readiness assessor makes upgrade quality visible before implementation. Scores cite CMDB CI, patch gap, and compatibility flag where data exists. Empty fields stay empty. CAB retains approval authority, but it reviews evidence instead of hunting for it in the meeting.
[REDACTED]
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first