Replacing a site-to-site VPN without changing network topology is an incremental migration, not a forklift redesign. Keep the existing IP plan, routes, and firewalls in place, then add an identity-based overlay beside the VPN, move one service connection at a time, and remove tunnel dependencies only after traffic and rollback tests pass.
That approach matters because a VPN usually grants reachability to a network or subnet. A zero trust overlay can grant reachability to a named service instead. NIST SP 800-207 describes the same principle: authenticate and authorize the subject and device before establishing a session to a resource, rather than trusting network location.
What changes and what stays the same
The migration changes the connection mechanism, not the application topology. Your applications keep their existing private addresses and listeners while a software endpoint creates an outbound path and policy controls which identity can reach each service.
Keep these parts during the first phase:
- Existing VLANs, subnets, and private IP addresses
- Application ports and service discovery records
- Cloud route tables and on-premises routing
- Firewalls and the current site-to-site VPN for rollback
- Monitoring, SIEM, and change-control processes
Add only the pieces needed for the parallel path:
- An endpoint or connector at each participating site
- A cryptographic identity for each endpoint
- A policy that maps identities to specific services
- Connection logging and health checks
- A test route for a small, understood workload
This is different from replacing the network with another set of subnets or building a new transit hub. The underlying network carries the overlay traffic. The overlay decides which application connection is allowed.
Why a site-to-site VPN replacement needs a parallel run
Run the VPN and replacement path together until the new path has passed functional, failure, and rollback tests. A parallel run protects production while exposing assumptions about DNS, asymmetric routing, MTU, source addresses, and hard-coded allowlists.
A site-to-site VPN can make a remote subnet appear local. That convenience often hides broad access. If a host on one side is compromised, the attacker may be able to probe other hosts that the tunnel makes reachable. The CISA Zero Trust Maturity Model treats network and environment controls as part of a broader move toward resource-level, policy-driven access.
An overlay migration narrows the test scope. Start with one client and one service, not an entire branch. You can answer a concrete question: can identity A reach service B on port C, and can every other identity not reach it?
Step 1: Inventory the VPN before changing it
Document every dependency before you touch the tunnel. The inventory is your migration boundary and your rollback plan.
Capture:
- Local and remote subnets, selectors, and route priorities
- Tunnel endpoints, authentication method, and encryption settings
- Allowed ports and protocols by application
- DNS names, private records, and split-horizon behavior
- NAT rules and source-address expectations
- Firewall rules on both sides
- Monitoring probes, alerts, and service-level objectives
- Batch jobs, backups, replication, and administrative access
For each flow, record the source identity, destination service, port, protocol, expected latency, and business owner. Do not write “branch to data center” as the source and destination. Write “inventory-api-client to inventory-api on TCP 8443.” That level of detail becomes the new policy.
Step 2: Choose a pilot that proves the model
Choose a low-blast-radius service with a clear owner and a reversible change. A read-only API, reporting database replica, or internal web service usually works better than a domain controller, payment processor, or replication link for the first test.
The pilot should exercise the hard parts without putting core operations at risk. Check that it has:
- A known client and server
- A stable health check
- A test account or workload identity
- A documented firewall path
- A clear success metric
- A maintenance window for failover testing
The success metric should be observable. Examples include “the reporting worker completes its scheduled query through the overlay,” “the client cannot connect to an unrelated database,” and “the existing VPN can carry traffic after the overlay is disabled.”
Step 3: Deploy outbound-only endpoints
Install one software endpoint at each side of the pilot path. Place it on an existing host, gateway, or workload location that can reach the application over the current network. The endpoint should initiate outbound connections so the site does not need a new public listener or inbound firewall exception.
The deployment sequence is simple:
- Register the endpoint and issue its cryptographic identity.
- Confirm that it can establish its outbound control and data paths.
- Verify time synchronization and certificate or identity renewal.
- Confirm local reachability from the endpoint to the target service.
- Keep the VPN route active while you test the new path.
An endpoint does not replace the application firewall. It adds a policy decision before the application connection exists. That distinction is useful when the application still uses legacy IP addresses and the network team cannot redesign addressing.
Step 4: Translate VPN rules into service policy
Write one policy statement for each approved flow. The policy should name the source identity, destination service, protocol, and port. Avoid copying an entire subnet allow rule into the new system.
A useful policy model looks like this:
| Policy element | Example | Migration question |
|---|---|---|
| Source identity | reporting-worker-prod | Which workload is calling? |
| Destination service | inventory-api | Which service must it reach? |
| Protocol and port | TCP 8443 | What is the smallest network permission? |
| Environment | Production | Is test access separate? |
| Time or posture | Valid identity and healthy endpoint | What must be true before access? |
| Audit record | Allow or deny with identity | Can the team prove the decision? |
Use deny-by-default behavior for services that have not been mapped. Test both sides of the rule. An allowed request should succeed, and a request from an unapproved identity should fail before it can scan the destination network.
This is where the approach differs from a conventional VPN gateway replacement. A gateway can preserve the old tunnel shape. A policy-based overlay lets you preserve the IP topology while changing the trust boundary from “inside this subnet” to “this identity may reach this service.”
Step 5: Cut over one flow at a time
Move a single application flow by giving the pilot client a preferred overlay path while leaving the VPN available. Do not change every route, ACL, and DNS record in one window.
Use this cutover sequence:
- Establish the overlay path and verify the endpoint identities.
- Apply the least-privilege service policy.
- Run application health checks from the pilot client.
- Compare latency, error rate, throughput, and logs with the VPN baseline.
- Observe the flow through a normal operating period.
- Expand to the next client or service only after the owner signs off.
For applications that use fixed private addresses, the overlay can often carry the connection without changing the address the application sees. For applications that depend on source IP allowlists, update the allowlist only when testing proves the effective source address has changed. Never assume the address behavior from a diagram.
Step 6: Test failure and rollback
The migration is not complete when the happy path works. It is complete when the team knows what happens if an endpoint, controller, certificate, route, or policy fails.
Test at least these cases:
- The overlay endpoint stops
- The control-plane connection is unavailable
- The service endpoint is unavailable
- An identity expires or is revoked
- A policy is removed
- The underlying WAN path fails
- The VPN is restored as the fallback
- An unapproved host attempts access
Record the expected behavior and the observed behavior. A service that fails closed is usually safer than one that silently falls back to broad network access. If operational availability requires fallback, document the fallback scope and alert on its use.
Keep the VPN configuration unchanged until the pilot has passed rollback. The fastest rollback is usually a policy or route preference change, not a rushed rebuild of the old tunnel.
Step 7: Expand without redesigning the network
Expand by service group, site, or environment. A practical order is development, a non-critical production service, a complete application dependency group, and then shared infrastructure. Each step should add policy and identity, not a new mesh of tunnels.
At every expansion, compare the new path with the inventory. Remove stale VPN permissions only after no active flow depends on them. Look for hidden dependencies such as monitoring agents, patch repositories, time services, license servers, and backup targets.
The result should be a smaller set of approved service connections, not a second flat network. That is the operational value of microsegmentation: you reduce the reachable set without moving every workload into a new VLAN. The existing zero trust implementation guidance for cloud workloads covers the wider architecture; this procedure focuses on a site-to-site migration that leaves topology intact.
Common migration failures
Most failed site-to-site VPN migrations are not caused by encryption. They come from incomplete dependency mapping and unclear ownership.
Recreating subnet trust in a new product
If the new policy says “branch subnet can reach data-center subnet,” you have preserved the VPN’s blast radius. Start with named services and identities. Add broader access only when a documented dependency requires it.
Changing DNS and connectivity together
Changing service discovery, routes, and transport in one window makes faults hard to isolate. Keep the application name stable where possible, and test the connection path independently before changing records.
Forgetting non-application traffic
Backups, monitoring, identity services, and patch systems often use different ports and schedules. Include them in the inventory or plan a separate migration wave.
Removing the VPN too early
The old tunnel is a rollback control during migration. Remove it only after traffic logs show no dependency, owners approve the change, and the recovery procedure has been tested.
Treating logs as an afterthought
IP addresses show where a packet came from. An identity-based record can show which endpoint or workload was authorized to reach which service. Send the records to the same SIEM and incident process your team already uses.
When this approach is the right fit
An in-place overlay migration fits teams that need to replace site-to-site VPN access but cannot renumber networks, rebuild firewall zones, interrupt production, or wait for new circuits. It also fits mixed estates where one side is a branch, another is a cloud VPC, and a third is an operational site.
It is not a substitute for fixing an unhealthy WAN, redesigning an application that has no clear service boundaries, or meeting a requirement for a particular physical transport. It changes authorization and reachability. It does not remove the need for reliable underlay connectivity or sound application controls.
For a managed implementation, NetFoundry describes an outbound-only model in which endpoints authenticate before a specific service connection is established. Its zero trust site-to-site connectivity material describes the same topology-preserving goal: connect sites, clouds, OT environments, and partner networks without inbound ports or a network redesign.
FAQ
Can I replace a site-to-site VPN without changing IP addresses?
Yes. Keep the existing addresses and routes, deploy the replacement path beside the VPN, and migrate service flows incrementally. Validate source-address behavior for applications that use IP allowlists.
What is the safest site-to-site VPN migration plan?
The safest plan is inventory, pilot, parallel run, one-flow cutover, failure testing, and staged expansion. Leave the existing VPN available until owners confirm that the replacement path works and rollback has been tested.
Is a VPN gateway replacement the same as zero trust connectivity?
No. A gateway replacement can preserve network-level trust inside a tunnel. Zero trust connectivity evaluates identity and policy for a specific resource or service before allowing the connection.
Do I need new firewall rules to replace site-to-site VPN?
Not necessarily. An outbound-only design can use existing egress access and avoid new inbound listeners, public IPs, and inbound firewall exceptions. Confirm egress requirements with your network and security teams before deployment.
How do I migrate a site-to-site VPN to cloud workloads?
Start with one cloud workload and one on-premises service, then create an identity-to-service policy for that flow. Keep the cloud route and VPN active during the pilot, measure the baseline, and remove broad tunnel permissions only after dependent flows have moved.
Will replacing the VPN stop lateral movement?
It can reduce lateral movement when policy authorizes specific identity-to-service connections instead of whole subnets. The result depends on complete policy coverage, correct endpoint identity, and controls that prevent unauthorized fallback paths.
Related articles
- How to Implement Zero Trust for Cloud Workloads
- Zero Trust Tools for Cloud Workloads: A How-To Guide
- Best Zero-Trust Workload Connectivity Platforms
Sources & References
- NIST Zero Trust Architecture – resource-level authorization principles
- CISA Zero Trust Maturity Model – zero trust implementation guidance
- NetFoundry Site-to-Site Connectivity – outbound-only overlay model
- NetFoundry OpenZiti Documentation – open-source identity-based networking concepts
