Roughly 65% of enterprises say they plan to replace their traditional VPN with zero trust network access, and the ZTNA market is projected to grow from about $1.34 billion in 2025 to $4.18 billion by 2030. Those numbers tell you where the industry is going. They do not tell you how to get there, because every vendor publishes only its own half of the story — the onboarding guide for its product, never the 12 to 24 months when VPN and ZTNA run side by side and your help desk fields tickets for both.
This is the missing middle: a phased playbook for a VPN to ZTNA migration that survives contact with legacy applications, plus honest mechanics for the three platforms most enterprises shortlist — Zscaler Private Access, Palo Alto Networks Prisma Access, and Microsoft Entra Private Access.
The honest starting point: VPN won’t hit zero
Every ZTNA pitch deck ends with the VPN concentrator in a dumpster. Real migrations don’t. Legacy applications that lack modern authentication — thick clients speaking proprietary protocols, server-initiated connections, unauthenticated printer and scanner traffic, that ERP module nobody has touched since 2014 — will resist brokered, identity-centric access. Plan for a residual VPN footprint of 5–15% of your application estate for years, or budget the application-remediation work to eliminate it.
The takeaway for the steering committee: the goal is not “zero VPN.” The goal is shrinking the flat-network blast radius from everything to a short, named list of exceptions with an owner and a review date. Frame it that way on day one and the project survives its first awkward legacy app. Frame it as VPN elimination and you will be explaining a “failed” migration to the board in 18 months.
Phase 1 — Inventory apps and their auth
You cannot broker access to applications you cannot name. Start with 4–8 weeks of discovery: pull VPN logs, NetFlow, and firewall data to build the real application list — not the CMDB fiction. Most enterprises find far more internal apps than they expected. Then classify each app on two axes:
- Auth readiness — does it speak SAML/OIDC, can it sit behind a proxy with header-based auth, or is it hard-coded to NTLM, Kerberos-only, or nothing at all?
- Traffic pattern — client-initiated web or TCP (easy), long-lived sessions and VoIP (harder), server-initiated or peer-to-peer like remote support tools and softphones (hardest; check your vendor’s connector support explicitly).
The major platforms now help here — Zscaler’s AI-powered app discovery builds segmentation policy suggestions from observed traffic, and Microsoft’s Quick Access mode lets you onboard broad IP ranges first and tighten to per-app policy later. Use the tooling, but keep a human owner per application. Discovery output is your migration backlog; treat it like one.
Phase 2 — Run ZTNA and VPN in parallel
Parallel running is where migrations quietly die, so set rules before you start. Deploy the ZTNA client alongside the VPN client to a pilot ring of 5–10% of users — include your loudest power users deliberately, because they find breakage fast. Route only pilot apps through the broker; everything else stays on VPN. Critically, make the routing decision in the client, not the user: if users have to choose which tunnel to use, they will choose wrong and blame the new thing.
Two thresholds worth stealing. First, hold each app in parallel for two full business cycles — usually two months, long enough to catch month-end batch behavior — before cutting VPN routes to it. Second, cap the parallel period at 24 months total. Past that, you are paying double licensing, double client overhead, and double help-desk training indefinitely — the migration has become a lifestyle.
Phase 3 — Migrate app-by-app, not user-by-user
The instinct is to migrate by department. Resist it. Migrating user-by-user means every user needs every app working on day one — one broken legacy app rolls back the whole cohort. Migrating app-by-app means an application is either served by the broker for everyone or it isn’t, and your exception list shrinks visibly week over week. It also forces the conversation that matters: for each app, either it gets a connector and a policy, it gets remediated to modern auth, or it goes on the residual-VPN exception list with a named owner.
Sequence by risk and ease: start with internal web apps behind SSO (fast wins, visible progress), then TCP thick clients, then the awkward tail. And write policy for non-human identities as you go — service accounts, RPA bots, and increasingly AI agents need scoped access paths too, a problem we unpack in our AI agent identity governance guide. Bolting that on after the human migration means doing discovery twice.
Phase 4 — Decommission at roughly 80% coverage
Do not wait for 100%. Once roughly 80% of internal applications are served through the broker, start pulling VPN infrastructure: shrink concentrator capacity, cut licensing tiers at renewal, and move the residual VPN to a segmented enclave that reaches only the exception-list apps — not the flat network. That last step is the one enterprises skip, and it is the whole point. A legacy VPN that lands users in a five-app enclave is a contained risk; one that lands them on the old flat network means you ran a two-year project without changing your blast radius.
The VP-ready takeaway: 80% brokered coverage is the decommission trigger, and the residual VPN must terminate in an enclave, not the core.
Vendor mechanics: Zscaler, Palo Alto, Microsoft
| Zscaler Private Access | Prisma Access (Palo Alto) | Entra Private Access (Microsoft) | |
|---|---|---|---|
| Model | Cloud broker; Client Connector plus outbound App Connectors | SASE fabric with firewall-grade inspection on the access path | Identity-first; Conditional Access extended to private apps |
| Strongest at | Mature broker at scale; app discovery and segmentation | Inline threat inspection of private-app traffic; PAN-OS shops | Entra ID-standardized orgs; licensing already in the suite |
| Watch for | Premium pricing; platform lock-in as scope grows | Module and licensing sprawl; highest typical TCO | Younger product; deepest value assumes a Microsoft stack |
| Best fit | Large enterprises with aggressive segmentation goals | Security-first shops wanting one inspection stack everywhere | M365-heavy mid-to-large orgs optimizing spend |
Zscaler Private Access
ZPA is the most battle-tested pure broker: outbound-only App Connectors mean nothing is exposed inbound, and its AI-assisted user-to-app segmentation genuinely shortens Phase 1. Where it is weaker: costs climb as you extend coverage from remote workers to office users and third parties, and you are committing to Zscaler’s cloud as the control plane for everything. Best fit for large enterprises that want segmentation depth and can absorb premium pricing.
Prisma Access (Palo Alto Networks)
Prisma Access’s differentiator is that private-app traffic gets the same threat prevention stack — intrusion prevention, malware analysis, DNS security — as internet-bound traffic, and its ZTNA Connector handles app-side connectivity without inbound holes. The trade-off is complexity: multiple modules, fragmented licensing, and typically the highest total cost of the three, though Panorama-managed shops recover much of that in operational familiarity. We compared the two SASE heavyweights directly in our Zscaler vs Palo Alto SASE brief.
Microsoft Entra Private Access
Microsoft’s entry, part of the Global Secure Access family, extends the Conditional Access policies you already run for SaaS to private applications, and it has moved fast — B2B guest access and Intelligent Local Access shipped in late 2025, with browser-based BYOD access in preview as of early 2026. It is the value play if you already pay for Entra Suite or the newer M365 bundles that include it. It is also the youngest product here: inspection depth and non-Windows client maturity trail the specialists, as of mid-2026. Microsoft-centric organizations should shortlist it first; heterogeneous shops should pilot it hardest.
Frequently asked questions
Can ZTNA completely replace a VPN?
For most enterprises, not entirely — and not soon. Client-initiated web and TCP applications migrate cleanly; server-initiated traffic, legacy auth, and some VoIP or thick-client workloads do not. Plan for a 5–15% residual VPN footprint confined to a segmented enclave, and treat every app on that list as remediation debt with a named owner.
How long does a VPN to ZTNA migration take?
Budget 12–24 months for a mid-to-large enterprise: one quarter of discovery, one quarter of pilot, then app-by-app waves. Under 12 months usually means the inventory was skipped; past 24 months of parallel running means you are paying for two access stacks indefinitely and should force the exception-list decision.
Which applications don’t work well with ZTNA?
The usual offenders: server-initiated connections (remote support, some management tools), peer-to-peer traffic like softphones, unauthenticated device traffic such as printing and scanning, and anything hard-wired to legacy network auth. Vendor support varies — verify your specific protocols against each platform’s connector documentation before you commit to a decommission date.
Is ZTNA cheaper than a VPN?
Per-user list pricing is usually higher than VPN licensing, and you pay double during the parallel phase. The savings arrive later: retired concentrators, a smaller breach blast radius, fewer lateral-movement incidents, and — for Microsoft-licensed shops — ZTNA effectively bundled into suites you already buy. Model it over three years, not one; list pricing varies enough that you should negotiate all three.
Enterprise Techie publishes vendor-honest analysis like this daily — get the brief by email, free.