The situation
There is a change window on Saturday, and nobody can tell you it is safe.
The vendor published release notes for the device. Nobody published release notes for your room, which is the thing that will or will not still work on Monday morning.
What the release notes do not say.
Firmware notes describe a device in isolation. Your room is a codec, a DSP, a switch, a control processor and a display that have to keep agreeing with each other, and the interaction that breaks is almost never the one the note warns about.
So the change gets made on a Saturday by somebody who is fairly confident, and the failure surfaces on Monday in front of people. The rollback is the expensive part: it costs another window, and by then the calendar has moved on.
What to do about it
Rehearse it first, on a model rather than on the room.
- Tell it what you are about to change. The device and the version you are moving to. Read it off the gear, or type it in by hand if you would rather keep CrossCheck away from the device entirely.
- It models the change against your own kit. And checks the hazards that quietly take AV down, which is a wider set than the vendor documented.
- You get a verdict with the working under it. Go, Caution or No-Go, and what would break, and the fix.
- Make the change yourself. CrossCheck cannot flash firmware. It never touches the device, which is why it is safe to run the week before.
The tool for it
CrossCheck is the one for this.
Its catalog is 192 rules across 26 vendors: 75 hazard rules, 76 published end-of-support dates, 21 upgrade paths and 20 config migrations. Every rule cites the vendor advisory behind it.
Bring us the change in Saturday’s window.
One upgrade, rehearsed, before you commit a window to it.