Why the inventory is the whole job
Every migration plan that fails in an unpleasant way fails because the inventory was wrong, not because the cryptography was hard. The device was on a different release than recorded. The tunnel had a second peer nobody documented. The HA pair members were not running the same code. The tunnel everybody assumed was decommissioned was carrying a payments feed.
An inventory is not an asset list. It is the artifact that makes a migration decision defensible, which means it has to record the things a migration decision depends on — and only a few of those appear in a typical CMDB.
What to record per gateway
| Field | Why it matters |
|---|---|
| Exact model | Determines which software releases can be installed at all |
| Running software version, read from the device | The single most commonly wrong field in existing documentation |
| Licence tier | Some vendors gate cryptographic features by licence |
| Support lifecycle status | A device past software maintenance may never gain the capability |
| Management path | Determines whether a change can be pushed at scale or must be applied per device |
| HA role and cluster peer | Migration must be sequenced per member, and members can differ |
| Physical or virtual, and host platform if virtual | Affects both capability and change process |
| Owner | Someone has to approve the change window |
The version field deserves its own note. Record the full release string as the device reports it, not a rounded family name. The difference between two maintenance releases within the same train is frequently the difference between a tunnel that can migrate and one that cannot.
What to record per tunnel
| Field | Why it matters |
|---|---|
| Local and remote peer identity | The tunnel is the unit of migration, and it has two ends |
| IKE version | An IKEv1 tunnel has no post-quantum path at all |
| Negotiated proposal, from the SA | Configuration states intent; the SA states the result |
| Authentication method | Migrates separately from key establishment, on a different timeline |
| Peer ownership: internal or external | External peers set the timeline for that tunnel |
| Routing: static or dynamic | Dynamic routing means the change can affect path selection, not just the tunnel |
| What the tunnel carries | Drives business criticality and therefore wave placement |
| Change-control class | Determines the minimum lead time for this tunnel's wave |
Device state beats documentation
The rule is simple and it is worth enforcing: a field is confirmed only if it was read from the device or from the cloud provider's API. Everything else is marked unconfirmed and carries lower confidence into every decision built on it.
This is not pedantry. An inventory that mixes confirmed and assumed values without distinguishing them produces a migration plan whose failure modes are invisible until the change window. Recording confidence per field means the plan can say "these forty tunnels are scheduled on confirmed data; these twelve need a collection pass first" — which is an actionable statement.
Practical collection routes, in rough order of reliability:
- Direct read from the device — CLI, API, NETCONF, or a configuration export.
- Vendor management platform export — good coverage, but reflects what the manager believes, which can lag the device.
- Cloud provider API export — authoritative for cloud VPN gateways, and easy to automate.
- Configuration backup archives — useful, but only as current as the last backup.
- CMDB or spreadsheet — a starting point for knowing what to go and look at. Not evidence.
Structure it so it can answer questions
The inventory needs to answer, without rework:
- How many distinct platform-and-release combinations exist? This number, not the tunnel count, drives research effort.
- Which tunnels terminate on a peer we do not control? This set drives the programme's critical path.
- Which gateways are past, or approaching, end of software support? This set becomes a capital request.
- Which tunnels carry dynamic routing, and which are in HA pairs? These constrain wave composition.
- Which fields are unconfirmed, and on which devices? This is the remaining collection backlog.
If the inventory is a flat spreadsheet with one row per device, it will not answer the second or the fifth of those. Model gateways and tunnels as separate related sets from the start.
Common mistakes
- Recording the model but not the release. The model tells you what is possible; the release tells you what is true.
- One row per tunnel with a single "peer" column. A tunnel has two endpoints with independent capability, and the weaker one governs.
- Treating HA pairs as one device. Members drift. Verify and migrate them separately.
- Omitting decommission candidates. Tunnels nobody can account for are a finding, not a gap. Some of them are carrying production traffic.
- Not recording confidence. An inventory that cannot distinguish confirmed from assumed will produce a plan that cannot either.
What this does not cover
This guide covers what to record and why. It does not cover what any specific value implies about migratability — that mapping is per product and per release, and it lives in the compatibility matrix. Nor does it cover collection tooling, which is estate-specific and depends heavily on what management platforms are already in place.