Who this guide is for
You run somewhere between twenty and a few hundred site-to-site tunnels, across more than one vendor, with at least one cloud VPN gateway and at least one tunnel terminating on a device you do not control. You have been asked what it would take to migrate, and you do not currently have an inventory you trust enough to answer.
If that is not you — if you have five tunnels on one platform — most of this is overhead. Read the migration checklist instead.
Definitions used here
VPN estate. Every gateway, tunnel and peer relationship providing site-to-site or infrastructure connectivity, including cloud VPN gateways and tunnels terminating on partner-controlled equipment.
Key establishment. How the two peers agree a session key. This is what a post-quantum migration changes.
Authentication. How each peer proves who it is. A post-quantum key establishment migration does not change this. See ML-KEM and FIPS 203.
Migration wave. A set of tunnels migrated together under a single change record, chosen so that failure is contained and rollback is a single decision.
Blocker. A specific, named reason a tunnel cannot migrate now, with an owner and an option set. "Not supported" is not a blocker; "PA-3220 on 10.2.9, model not supported on the target train, refresh scheduled Q3" is.
Stage 1: Build an inventory you can trust
Nothing downstream works without this, and existing documentation is almost never sufficient. The failure is rarely that the CMDB is empty — it is that the CMDB records the model and not the running release, or records the release as of the last audit.
Collect, per gateway: exact model, exact running software or firmware version read from the device, licence tier, support lifecycle status, management path, and HA role. Per tunnel: both peer addresses, IKE version, current proposal, authentication method, whether the peer is internally or externally controlled, and what the tunnel actually carries.
The detail on how to do this is in building an enterprise VPN inventory. The point to carry forward is that the inventory must be derived from device state, not from documentation about device state.
Stage 2: Establish capability per device and release
For each distinct combination of platform, release and licence in the inventory, answer three questions:
- Which IKEv2 post-quantum mechanism does this exact combination support — RFC 9370 additional key exchanges, RFC 8784 preshared key mixing, or neither?
- Is it reachable through the configuration path this estate actually uses? A capability available only through a local CLI edit is not usable across a centrally managed fleet.
- What is required to get there from where the device is now — nothing, a configuration change, a software upgrade, a licence change, or replacement?
Do this per combination rather than per device. An estate of two hundred FortiGates usually reduces to four or five distinct combinations, and the research effort collapses accordingly.
Resist the temptation to answer at the vendor level. "Cisco supports it" is not an answer that survives contact with an estate containing IOS XE, ASA, Secure Firewall and Meraki MX.
Stage 3: Classify every tunnel
Every tunnel lands in exactly one of five categories. The classification is a property of the tunnel, not of either device, because it is constrained by the weaker peer.
| Classification | Meaning | Typical next action |
|---|---|---|
| Ready | Both peers already support the target mechanism | Schedule into an early wave |
| Upgradeable | Both peers can reach the target with a software or licence change you control | Sequence the upgrade, then the migration |
| Peer-dependent | Your side is ready; the peer belongs to another organisation | Start coordination now; schedule late |
| Replacement required | One peer cannot reach the target on any supported release | Hardware decision; price it into the plan |
| Blocked | Something else prevents it — regulatory, contractual, or an unresolved dependency | Record the owner and the unblocking condition |
The proportions in this table are the single most useful output of an assessment for an executive audience. "Sixty per cent ready or upgradeable, twenty-five per cent peer-dependent, fifteen per cent requiring replacement" is a decision-ready statement. A percentage readiness score is not.
Stage 4: Sequence into waves
Order waves so that each one teaches you something before the next one costs you more.
Wave 0 — canary. One or two tunnels, low business criticality, both peers internally controlled, ideally on the platform combination that covers the largest share of the estate. The purpose is to discover the surprises — fragmentation behaviour, unexpected rekey behaviour, a management platform that will not push the setting — while the blast radius is one tunnel.
Wave 1 — the dominant platform. The combination that covers most of the estate, now that the canary has de-risked it. This is where most of the volume gets done.
Wave 2 — remaining internally controlled platforms. Smaller populations, more per-platform variation, more effort per tunnel.
Wave 3+ — peer-dependent tunnels. Scheduled by counterparty readiness, not by your convenience. These waves are driven by other organisations' change calendars and are the most common cause of a migration programme running long.
Deferred register. Replacement-required and blocked tunnels, each with a named owner, an option set and a review date. This is not a wave; it is a standing item.
Two sequencing rules that repeatedly prove their worth: never migrate both members of an HA pair in the same change, and never put a tunnel that carries dynamic routing in the same wave as the first change to that platform.
Stage 5: Execute, verify, hand over
Per wave: pre-flight checks, configuration diff review by a human, staged change, apply, verify, capture evidence.
Verification means reading what was negotiated on the established security association. It does not mean re-reading the configuration you pushed. A proposal that still lists the classical-only option will negotiate the classical option and come up entirely healthy, and nothing will alert you. See verifying a post-quantum VPN migration for what to capture and from where.
Hand over with the updated inventory, the evidence set, the runbooks as executed rather than as drafted, and the deferred register with its owners intact.
Common mistakes
- Treating the tunnel count as the scope. Two estates with sixty tunnels each can differ by a factor of five in effort. Vendor diversity, external peers and change-control regime drive the work.
- Assuming vendor support means estate readiness. It is a necessary condition and nowhere near a sufficient one.
- Leaving partner coordination until the technical work is done. It has the longest lead time in the programme, and it can start on day one.
- Migrating key establishment and calling authentication done. They are separate properties on separate timelines.
- Verifying by reading configuration. Configuration is intent. The SA is the result.
- No rollback for a "safe" change. Renegotiation is a production event. Every wave needs a rollback that has been written down before the window opens.
Limitations of this guide
This guide describes method, not product capability. It deliberately makes no claim about which vendor or release supports which mechanism; those claims are recorded per product in the compatibility matrix with their own sources and review dates. It also assumes IKEv2. Estates with surviving IKEv1 tunnels need an IKEv2 migration first, as a separate change with its own plan.