How to use this
This is a working checklist, not a governance artifact. Each item exists because skipping it has a specific, known consequence, which is stated alongside it. Adapt the items; keep the reasons.
It assumes the wave has already been defined by an assessment — see the migration guide for how waves are composed.
Before the wave: pre-flight
Capability confirmed on both peers, at the exact running release. Not the product family, not the release the CMDB records. Consequence of skipping: the change window is spent diagnosing a device that was never capable.
Peer coordination complete for externally controlled tunnels. Written confirmation, a named contact, and an agreed window. Consequence: the tunnel drops and the counterparty is unreachable.
Configuration diff generated and reviewed by a second engineer. Reviewed against the intended end state, not just for syntax. Consequence: a valid configuration that does something other than intended.
Rollback written down and tested. The exact steps, not "revert the change". Where a software upgrade is involved, confirm the downgrade path exists at all — for several platforms it does not. Consequence: an extended outage while a rollback is improvised.
IKE fragmentation support confirmed on both peers. Post-quantum key material makes IKE messages substantially larger. Consequence: intermittent establishment failures that only appear from constrained paths.
HA member order defined. Which member first, what confirms it is safe to proceed, how to abort mid-way. Consequence: both members changed, both broken, no working path.
Dynamic routing impact assessed. Which sessions will re-establish, expected prefixes, expected convergence time. Consequence: the tunnel comes up and the routing behind it does not.
Monitoring suppression scheduled and time-boxed. Consequence: either an alert storm, or suppression left on and a real failure missed.
Business owner notified with a realistic window. Consequence: an escalation during a planned change.
During the wave: change window
Capture pre-change state first. Current SA parameters from both peers, current routing state. This is half the evidence record and it cannot be recreated afterwards. Consequence: no baseline to compare against or to roll back to.
Apply to one HA member. Verify. Then the other. Consequence: covered above, and it is the most expensive mistake on this list.
Verify establishment before proceeding to the next tunnel. Not at the end of the batch. Consequence: twenty tunnels changed, one broken, unclear which change caused it.
Watch the first rekey where the wave is short enough to permit it. Establishment and rekey are different code paths. Consequence: the wave closes green and tunnels fail hours later.
Stop the wave on the second unexplained failure. One surprise is information; two is a pattern that was not understood before the window opened. Consequence: a small problem propagated across the estate.
After the wave: verification
Read the negotiated key exchange method from the established SA, on both peers. This is the finding being evidenced. Re-reading configuration proves nothing — a proposal still offering a classical-only option will negotiate it and come up healthy. Consequence: a tunnel recorded as migrated that is exactly as exposed as before.
Confirm authentication method is unchanged. It should be. Confirming it is how you know nothing else moved. Consequence: an unnoticed change to a second property.
Confirm routing re-established with the expected prefixes. Consequence: traffic taking an unintended path.
Test failover and verify the standby member. Consequence: half the HA pair unverified.
Confirm the application actually works, from the far side. Consequence: a tunnel that is up and carrying nothing.
Sample the untouched tunnels on any device that received a software upgrade. They were changed too. Consequence: collateral breakage attributed to something else weeks later.
After the wave: closure
Capture raw device output, not a summary. A ticked box evidences a tick. Consequence: an evidence record that proves nothing under scrutiny.
Update the inventory with the new state. Before the next wave plans against it. Consequence: the next wave plans against stale data.
Record what surprised you. Every wave teaches something about this estate; the next wave should not relearn it. Consequence: the same surprise, repeatedly, at increasing scale.
Close or re-date any deferred item this wave touched. Consequence: a deferral register that quietly stops reflecting reality.
Limitations
The per-platform commands, API calls and configuration syntax that implement these checks are platform-specific and belong in the runbook for each platform. This checklist covers what to check and why, not how to check it on a given device.