What a VPN Cutover Must Preserve From a Private Circuit

Private circuits are easy to describe and hard to replace, because the contract covered more than a cable. It carried a handoff, an address plan, a latency expectation and a support arrangement, and the tunnel that replaces it inherits all four whether anyone wrote them down or not. Cutovers fail when the team copies the routing configuration and calls the rest an operations problem. Start from the requirements, then prove each one on the new path before the old one is cancelled.

Turn the circuit into a list of properties

The first question is what the old service actually handed over: a routed link with a small subnet, or a Layer 2 segment shared between sites. That distinction decides whether an IP tunnel can reproduce it at all, because a tunnel carries packets between two addresses and does not carry broadcast discovery or arbitrary EtherTypes. A circuit that presented itself as a switch port is a different migration from one that presented a /30.

Write down the site prefixes, the gateway addresses, the applications that embed addresses in their own configuration, and the prefixes that overlap somewhere else in the estate. An address plan that survives the migration is a design output, not an assumption. Those four lists also become the acceptance criteria later, so keep them where the testers can read them.

Route the new path in both directions

A tunnel that comes up is only half a path. The far side needs a route back to every local prefix, and the local side needs to prefer the tunnel for those prefixes without stealing traffic that should still leave through the internet. Asymmetric forwarding is the usual symptom of getting one of those halves right. Inspect the far side's table as carefully as your own, because the return path is the one nobody configured.

ip route get 10.20.0.10

Policy routing makes the split explicit: mark the traffic that belongs to the site pair and give it a table whose default is the tunnel. IPsec supplies the protected association and the policy that decides what enters it, but not the routes around it, as the IPsec architecture describes. When the mark matches too broadly, ordinary web traffic from the site enters the tunnel as well and leaves through the wrong egress.

Switch with a rollback you have already tested

Two live paths with different owners invite asymmetric forwarding, so bring the new one up inside a defined window and move prefixes in a stated order. Keep the old circuit configured and keep an out-of-band management path that depends on neither tunnel. Move one prefix at a time where the applications allow it, and watch the session table between moves.

Decide in advance what evidence authorizes the switch and what condition triggers the rollback. A rollback that requires repairing the new VPN through the failed connection is not a rollback. State the trigger as a measurable condition rather than as a feeling in the room.

Accept with the traffic the circuit actually carried

Ping proves reachability and little else. Test name resolution, the long-lived sessions, the denied flows and the packet sizes the old path handled without fragmentation. MTU is where tunnels most often differ from a circuit, because encapsulation consumes bytes the application assumed were available. Measure the largest payload that passes without fragmentation in both directions, not only toward the server.

ping -M do -s 1400 -c 3 10.20.0.10

If a 1400-byte payload passes and 1472 does not, the path maximum is smaller than the applications expect and you have found a real regression, not a cosmetic one. Compare that result with the requirements written in the first step, and retire the circuit only when the owners of those applications accept the measurement. That signature is what turns a successful test into an accepted migration.