VPN-to-ZTNA Migration Plan (2026)

1Tell us where to send it
Your name and work email — nothing more.
2Check your inbox
Your guide arrives in seconds, not days.
3Use it with your team
Editable and ready to share — make it your own.

A peek inside

See exactly what you're getting

Free PDF

Spotsaas · 2026

VPN-to-ZTNA Migration Plan

✓ Why migrate, and the core shift

✓ VPN vs. ZTNA at a glance

✓ Migration phases

✓ Migration gotchas to plan for

Get the guide →

What it is

The VPN-to-ZTNA Migration Plan is a practical playbook for moving from a flat, network-level VPN to zero-trust network access — replacing 'on the network = trusted' with per-application, identity-and-posture-based access, without a risky big-bang cutover. It opens with a side-by-side model comparison (network-level vs. per-request trust; whole-subnet reach vs. only granted applications; largely-unrestricted lateral movement vs. default-deny app isolation; public VPN concentrator vs. no inbound ports; coarse IP/port logs vs. per-user, per-app session logging) so the case for migrating is concrete, then lays out five phases from inventory through VPN decommission.

The phases are sequenced to be reversible. Phase 1 inventories every app reached over VPN — hostname, ports, location, owner — maps who needs each and from what devices, and classifies apps by protocol fit (web/HTTP migrates easily; thick-client, server-initiated, or peer-to-peer protocols need agent-based connectors, not clientless). Phase 2 stands up the ZTNA broker and outbound-only connectors, integrates SSO/IdP, and defines per-app policy (identity groups, MFA, device posture) with default-deny segmentation. Phase 3 runs VPN and ZTNA in parallel, onboarding a pilot and migrating low-risk apps first while VPN stays as fallback. Phase 4 cuts over per app by removing each app's VPN route once ZTNA is proven — the moment the flat path actually closes — keeping a documented rollback. Phase 5 decommissions the VPN, closing inbound ports and reclaiming licenses while keeping a tested break-glass path.

It's built around the failure modes that make migrations painful: protocols that clientless ZTNA can't broker, posture signals that aren't trustworthy enough to gate on, hard-coded IPs and service-to-service calls that assumed a flat network, and the temptation to skip the parallel phase and turn every edge case into a same-day outage. The plan enforces the app-by-app, fallback-protected sequence that keeps the migration boring. It builds on the endpoint posture checklist (the device conditions ZTNA enforces) and realizes the network-layer side of the zero-trust security checklist.

What it's used for

VPNs grant flat network reach and broad lateral movement that zero trust is meant to eliminate, but ripping one out carelessly causes outages. Teams use this plan to migrate deliberately, app by app:

✓ Planning a full VPN-to-ZTNA migration as a phased, reversible project rather than a big-bang cutover that turns every edge case into a same-day outage.
✓ Inventorying every application reached over the VPN — hostname, ports, location, owner, and who needs it — as the baseline the whole migration is sequenced from.
✓ Classifying apps by protocol fit so web/HTTP apps migrate clientless while thick-client, server-initiated, and peer-to-peer protocols are designed for agent-based connectors instead of silently failing.
✓ Standing up the ZTNA broker with outbound-only connectors and default-deny segmentation, eliminating the public VPN concentrator and its open inbound ports.
✓ Defining per-app access policy on identity, MFA, and device posture, so 'on the network' stops meaning 'trusted' and each app is reachable only by its named policy.
✓ Running VPN and ZTNA in parallel with the VPN as fallback, migrating low-risk apps first and moving users' muscle memory before any route is removed.
✓ Cutting over and decommissioning safely — removing each app's VPN route only after ZTNA is proven, keeping a documented rollback, and retaining a tested break-glass path after the concentrators are shut down.

Who uses it

A VPN-to-ZTNA migration touches networking, security, identity, and every app owner. The plan coordinates them through its phases.

Network and infrastructure engineersThey run the VPN today and deploy the ZTNA broker and connectors, manage the parallel run, and execute the per-app route removal that actually closes the flat path.

Security architects and zero-trust leadsThey own the model shift — default-deny segmentation, per-app policy, posture conditions — and ensure the migration genuinely eliminates lateral movement rather than recreating flat reach.

Identity / IAM administratorsThey integrate SSO/IdP with the broker and define the identity-group, MFA, and device-posture conditions that gate each application.

Application ownersThey confirm their app's protocol fit (clientless vs. agent-based), validate access under ZTNA during parallel run, and sign off before their app's VPN route is removed.

IT operations and help-deskThey support the pilot and ringed waves, field migration tickets, and rely on the documented per-app rollback to contain breakage.

CISOs and security leadersThey sponsor the migration for the risk reduction — no inbound ports, no flat reach, per-user/per-app visibility — and need the phased plan to show it's being done without an outage.

Context & good to know

The VPN's defining weakness is its trust model: once you're connected, you're 'on the network,' and the network largely trusts you. That means broad subnet reach, mostly-unrestricted lateral movement, and a public-facing concentrator with open inbound ports — exactly the conditions that let one compromised credential or device roam. ZTNA inverts this: nothing is reachable by default, each application is granted individually based on verified identity and device posture, connectors make only outbound connections so there are no inbound holes, and every session is logged per-user and per-app. The migration is how you trade the flat model for the verified one.

Protocol fit is the technical reality that derails naive migrations. Web and HTTP apps move easily — often clientless, through a browser. But thick clients, server-initiated protocols, and peer-to-peer traffic (think certain RDP setups, SMB, legacy line-of-business apps) can't be brokered by clientless ZTNA; they need an agent-based connector, and if you don't design for that up front they simply fail to migrate, silently, at cutover. Classifying every app by protocol fit in Phase 1 is what prevents that surprise.

The parallel-run phase is the difference between a calm migration and a string of outages. Running VPN and ZTNA side by side, with the VPN still serving each app as a fallback until ZTNA is proven for it, means every edge case — a hard-coded IP, a service-to-service call that assumed same-subnet reachability, a license server that expected a flat network — surfaces while there's still a working path. Skipping parallel run turns each of those into a same-day, all-hands outage. The plan's app-by-app cutover, where the VPN route is removed only after soak passes, keeps a rollback available at every step.

Two things are easy to forget and expensive to skip: posture trustworthiness and break-glass. Posture is a core ZTNA control, but if your EDR/MDM coverage is patchy, posture conditions will either block legitimate users or wave through unhealthy ones — which is why the endpoint posture checklist is a prerequisite, not a nice-to-have. And once the VPN is gone, an IdP or broker outage can lock out all remote access; the plan insists on keeping a minimal, tested break-glass path documented after decommission. Done right, the migration ends with no public inbound ports, no flat reach, and far better visibility — the network-layer realization of zero trust.

✓ Independent · vendors can't pay to rank

Built on verified data, not vendor spin

Every Spotsaas resource draws on the Spotsaas Score — a blend of verified review ratings, review volume, and feature depth across 57 remote access software tools. Refreshed regularly; data as of June 2026.

FAQ

Questions, answered

What is ZTNA and how does it differ from a VPN?

ZTNA (zero-trust network access) grants access to individual applications based on verified identity and device posture, evaluated per request, rather than putting a user 'on the network.' A VPN connects you to a subnet and largely trusts you once connected, allowing broad reach and lateral movement. ZTNA is default-deny: each app is reachable only by its named policy, connectors are outbound-only so there are no inbound ports, and every session is logged per-user, per-app.

Why migrate off VPN at all?

Because the VPN's flat trust model is what lets a single compromised credential or device roam your network. ZTNA eliminates lateral movement (apps are isolated by default), removes the public inbound exposure of a VPN concentrator, makes device posture a continuous condition, and gives per-app visibility instead of coarse IP/port logs. It's the network-layer expression of zero trust — verify every request rather than trust the network.

Can I migrate everything at once?

You shouldn't. The plan deliberately runs VPN and ZTNA in parallel and cuts over app by app, because a big-bang cutover turns every edge case — a hard-coded IP, a service-to-service call, a protocol that clientless ZTNA can't broker — into a same-day outage. Migrating in waves with the VPN as fallback, and removing each app's route only after it soaks cleanly on ZTNA, keeps a rollback available throughout.

Which apps are hard to migrate to ZTNA?

Apps using server-initiated or peer-to-peer protocols, and thick clients — things like certain RDP configurations, SMB, and legacy line-of-business software. Clientless/web ZTNA can't broker these; they need an agent-based connector. If you don't identify and design for them in the inventory phase, they fail to migrate silently at cutover. Web/HTTP apps, by contrast, move easily and often clientless.

How do ZTNA connectors avoid opening inbound ports?

Connectors deployed next to each app group make only outbound connections to the broker — they 'dial out' rather than listen for inbound traffic. That means no public inbound ports and no VPN-concentrator-style attack surface. Removing those inbound holes is one of the biggest security wins of the migration, and the reason Phase 5 can shut down concentrators and close their public ports entirely.

What breaks when the flat network disappears?

Usually hard-coded IP addresses, internal service-to-service calls, and license servers that assumed same-subnet reachability — dependencies that quietly relied on the VPN's flat reach and only surface at cutover. The parallel-run phase exists to flush these out while the VPN is still available as a fallback, so each one is a fixable edge case rather than an outage.

Do I still need MFA and device posture with ZTNA?

Yes — they're the conditions ZTNA evaluates. ZTNA decides access per request based on identity (with MFA) and device posture (managed, encrypted, patched, EDR present). Posture is a core control, so trustworthy MDM/EDR coverage is effectively a prerequisite; if it's patchy, your posture conditions either block legitimate users or wave through unhealthy ones. The endpoint posture checklist is the companion that gets this right.

Should I keep any VPN after decommission?

Keep a minimal, documented, tested break-glass remote path for emergencies. Once the VPN is fully gone, an IdP or ZTNA broker outage can lock out all remote access, so the plan retains an emergency fallback even after the main concentrators are shut down and their inbound ports closed. It's a deliberately small, sealed path — not the old flat VPN — used only when the primary access route is unavailable.

Is RDP or TeamViewer better for remote access during this migration?

They solve different problems. RDP is a Windows remote-desktop protocol that, exposed directly, is a common attack surface and assumes network reachability — which is exactly the flat-access pattern ZTNA replaces; behind a ZTNA connector it can be brokered safely as an agent-based app. TeamViewer (and similar tools) are managed remote-access products with built-in MFA, encryption, and session recording. For zero-trust remote access you'd either broker RDP through ZTNA or use a managed tool, rather than exposing raw RDP over a flat VPN.

Keep exploring