The Upgrade Pre-check Standard
A pre-check is complete when a competent engineer at the vendor, reading only the record, would agree the team did everything it could before the change. UPS-1 defines what that record contains, for any software or hardware.
Ten domains
Every check belongs to one domain. A product checklist meets UPS-1 only when each core domain has at least one blocker check.
Supportability and path
Supported upgrade path, no back-in-time, interoperability, end of support, licensing and entitlement.
Hardware and firmware compatibility
Hardware compatibility list, firmware and driver versions, CPU and boot device support.
Health baseline
Clean health before the change: services, clusters, replication, alarms, errors.
Capacity and resources
Disk, memory, CPU, failover capacity and maintenance-mode headroom during the change.
Security, certificates and credentials
Certificate validity and strength, ciphers and protocols, passwords, accounts and keys that the upgrade touches.
Configuration and deprecations
Removed or changed features, unsupported customisations, settings that block or break the upgrade.
Dependencies and integrations
DNS, NTP, identity, backup, monitoring, automation and every system that calls this one.
Backup, recovery and rollback
A tested way back: backups, snapshots, restore procedure, rollback decision point.
Plan, people and change control
Approved change, window, runbook, vendor support case, communication, staff and access.
Validation and acceptance
Post-change tests that prove the service works, and the agreed acceptance criteria.
What every check states
- Severity. Blocker (do not start), high (start only with a written reason), medium, low.
- Phase. Planning (days before), pre-change (last 24 hours), go / no-go (start of the window) or post-change validation.
- Why. The failure the check prevents, in one or two sentences. Required for blocker and high checks.
- How. The exact command, API call or UI path. Never "check the health".
- Expect. What a pass looks like, so two engineers reach the same answer.
- Evidence. Output, screenshot, either, or attestation, and the reference (KB, release note, guide).
Evidence rules
- A blocker or high check marked Pass carries evidence: pasted output of at least a few lines, or an attachment. Attestation checks (for example "change approved") are the exception.
- Not applicable needs a reason.
- A failed blocker needs a deviation: the risk, the mitigation and the owner. Any deviation sends the record to change approval, even when the product does not normally need it.
- After approval, earlier answers are frozen. Go / no-go and post-change checks are recorded during the window.
- A record closes as Successful only when the post-change validation is complete.
Separation of duties and signatures
- The requester cannot review or approve their own record. The technical reviewer cannot also give the change approval.
- Every approval and rejection is signed with a fresh second factor and recorded with its signature.
The attestation
At closure the record states: the number of checks and blockers, how many blockers passed with evidence, every accepted deviation with its reason, the signed approvals and the domain coverage, followed by a SHA-256 hash of the closed record. This is the page a vendor support engineer reads first.
Using the standard
UPS-1 is free to use and to cite. Vendors can publish conforming checklists for their own products through the publisher programme.