Core product 2
Post-Quantum VPN Migration Programs
Convert an approved migration roadmap into controlled vendor-specific changes, staged migration waves, verification evidence and operational handover.
Prerequisite
Migration starts from a verified assessment
PQVPN does not begin a migration programme without a verified inventory and a per-tunnel capability position. Not as a commercial gate — the assessment can be one you already have, or one your own team produced.
The reason is operational. A migration planned against an unverified inventory fails in the change window, on a device that turned out to be running a different release than the record said, in front of an audience. Every hour spent confirming the estate beforehand removes several from the recovery.
Delivery models
You choose how much PQVPN touches
The deliverables are identical across all three. Only the hands differ.
Customer-led
PQVPN produces the artifacts, runbooks and test plans. Your engineers execute every change. PQVPN reviews the evidence afterwards if you want a second pair of eyes.
Credentials: None required.
Joint delivery
Work splits by platform or by wave. PQVPN takes the platforms where specialist knowledge saves the most time; your team takes the rest and gains the knowledge as it goes.
Credentials: Scoped, time-bounded, or none — your choice per platform.
PQVPN-led
PQVPN delivers the programme end to end under your change control. Your team retains approval on every window and receives full handover at the end.
Credentials: Scoped and time-bounded, or executed through a runner you host.
Workflow
How a migration wave runs
Confirm desired state
Agree the target mechanism per tunnel, and what evidence will prove it.
Validate prerequisites
Confirm release, licence, peer capability and fragmentation behaviour before anything is scheduled.
Generate implementation artifacts
Produce the configuration, the diff, the test plan and the rollback plan together, as one reviewable unit.
Peer review
A second engineer reviews the intended end state, not only the syntax. Nothing reaches staging without this.
Stage changes
Load into the estate's own change system, in its own format, under its own approval.
Canary or pilot
One or two low-criticality tunnels first, on the platform combination that covers most of the estate.
Migrate by wave
Ordered by risk and dependency, with HA members always in separate changes.
Verify
Read the negotiated SA from both peers. Configuration is intent; the SA is the result.
Roll back when required
A written, tested rollback exists before every window opens. Stopping is a normal outcome.
Hand over
Updated inventory, evidence set, runbooks as executed, and the deferred register with owners intact.
Implementation methods
The right mechanism depends on the platform
There is no single tool that manages every enterprise network platform, and claiming otherwise produces migration plans that stall on contact with the estate. The method is chosen per platform, from what actually works there.
| Method | When it applies |
|---|---|
| Terraform | Cloud VPN resources and vendor platforms with a maintained, capable provider |
| Ansible | Fleets of similar devices with a reliable connection plugin |
| REST API | Vendor platforms with a documented configuration API |
| NETCONF / RESTCONF | Network operating systems with a stable model for the relevant configuration |
| Vendor management platform | Estates already governed centrally, where local changes would be overwritten |
| Vendor-native configuration | Platforms whose own tooling is the only reliable path |
| Reviewed CLI plans | Devices with no viable programmatic path — generated, diffed and human-reviewed, then applied |
| Linux configuration management | strongSwan and other software gateways, including overlay terminators |
Credentials and access
Access models, in order of preference
- Customer executes
- PQVPN generates the artifacts; your engineers apply them. No PQVPN access to any device.
- Customer-hosted runner
- Artifacts execute from a runner inside your environment, under your credentials and your audit trail.
- Temporary credentials
- Scoped to the devices in the wave, valid for the change window, revoked at the end of it.
- Vault or KMS integration
- Credentials brokered through your existing secret management rather than handed over.
- Vendor manager integration
- Changes applied through the management platform that already governs the estate.
Unsupported devices
What happens to the ones that cannot move
Some devices will not reach the target on any supported release. That is a finding with options, not a dead end, and each option is costed against what the tunnel actually carries.
| Option | Note |
|---|---|
| Firmware or software upgrade | Cheapest real fix where the model can run a supporting release |
| Licence change | Where capability is gated commercially rather than technically |
| Hardware refresh | Align with a refresh already in the budget wherever possible |
| Overlay gateway | Terminate a migrated tunnel on a gateway you control, in front of the legacy device |
| Compensating control | Application-layer protection, with its own post-quantum position established |
| Reduce what the tunnel carries | Move the sensitive flow rather than migrating the tunnel |
| Defer and track | Named owner, stated reason, review date. A legitimate outcome when it is explicit |
| Partner coordination | Where the constraint is a counterparty rather than a device |
Each option is examined in detail in options for legacy VPN gateways.
Verification
Proving what was negotiated
Verification reads the key exchange method actually negotiated on the established security association, from both peers. It does not re-read the configuration that was pushed.
The distinction matters because the common failure is silent. A proposal that still offers a classical-only option will negotiate that option, the tunnel will establish, monitoring will stay green, and the change will be recorded as complete. Nothing alerts.
Evidence is also captured after a failover and after a rekey, because both are separate code paths from establishment.
Risk controls
What sits around every change
- Preflight checks against the actual device, not the inventory record
- Configuration diffs reviewed by a second engineer
- Change windows agreed inside your existing governance
- Written, tested rollback before every window
- Canary tunnel ahead of every new platform combination
- Traffic validation from the far side, not only tunnel status
- Routing validation, including re-established dynamic sessions
- HA validation with a real failover test where policy permits
- Evidence capture from both peers, stored against the change record
Deliverables
What the programme produces
- Vendor-specific implementation artifacts
- Change plans in your own format
- Test plans per platform
- Rollback plans, written before the window
- Validation evidence from both peers
- Updated topology diagrams
- Runbooks as executed, not as drafted
- Handover workshop with your engineers
Questions
Migration FAQ
Discuss a migration program
Tell us where the estate is now — whether an assessment exists, and who you want executing the changes. The scoping form takes a few minutes and returns a preliminary complexity band.