Every TMOS upgrade that goes wrong goes wrong for one of about five reasons, and none of them are the upgrade itself. They are the things nobody checked before pressing go. Here is the checklist I run on every engagement, in order.
1. Confirm the platform is actually supported
Before anything else, confirm the target version supports the hardware. Older appliances drop off the supported list sooner than people expect, and a vCMP guest inherits the host's constraints, so the host has to move first.
- Check the target version against the supported platforms matrix
- Confirm there is disk space for a second boot volume
- Confirm the vCMP host is on a compatible version before any guest
2. Take a backup that is actually a backup
A UCS is the floor, not the whole plan. Take a UCS with the private keys included, copy it off the box, and record the master key. If you skip the keys, a restore onto replacement hardware will not bring your SSL profiles back.
If the only copy of your rollback lives on the device you are upgrading, you do not have a rollback.
3. Stage on a spare volume, never in place
Install to an inactive boot location rather than over the running one. Boot into it during the change window, verify config and traffic, and you keep a single-command path back to the previous volume the moment anything looks wrong.
That is the core of it. The full runbook adds config verification, an AVR baseline capture and a formal go / no-go gate, but these three steps alone prevent the large majority of failed upgrades I get called in to rescue.