The Question
Your organization has made the decision to move from legacy VPN to Zero Trust Network Access. The vendor has presented a migration guide. The project plan looks clean. The go-live date is circled on the calendar.
Then the migration begins, and reality diverges from the plan. Legacy applications that worked fine over VPN start throwing authentication errors. Thick-client applications that required the VPN IP pool for licensing validation stop working. A critical on-premises system used by the finance team has been hardcoded to accept connections only from a specific subnet — a subnet that no longer applies once traffic comes from a ZTNA connector.
The migration fails. The CISO authorizes an emergency VPN rollback. Six months and significant project budget are lost.
This pattern is not a failure of ZTNA as a technology. It is a failure of migration sequence. Organizations that attempt a big-bang VPN cutover — moving all users simultaneously — are setting themselves up for the failure described above. The organizations that succeed follow a phased sequence that builds coverage before cutting access.
VPN decommissioning is the goal — but organizations that set VPN decommission as the milestone instead of app coverage completion are the ones that fail and roll back.
Why This Matters Now
In Q3 2024, a mid-size professional services firm with approximately 4,000 employees attempted a network-wide ZTNA cutover over a single weekend. The firm had deployed Zscaler Private Access and completed a pilot with a subset of IT staff. The vendor's migration documentation indicated that legacy VPN could be disabled once ZTNA was configured.
The weekend cutover went smoothly in the pilot environment. Monday morning, roughly 40% of the workforce could not reach the firm's on-premises document management system — a legacy platform running on Windows Server 2016 that used Kerberos authentication tied to a specific Active Directory domain controller. The ZTNA connector was deployed, but Kerberos ticket routing through the connector required configuration changes that had not been identified during the IT-only pilot.
The help desk received over 600 tickets in the first two hours. By noon, the decision was made to re-enable the VPN. The ZTNA deployment was rolled back to pilot status, and the migration was paused for four months while the legacy application inventory was completed and each application's ZTNA compatibility was validated.
This incident is representative of a pattern Stackcurve observed across multiple ZTNA migration projects in 2024 and 2025. The failure mode is consistent: application compatibility issues that are invisible in small-scale pilots surface at scale, and organizations without a phased rollback plan are forced into emergency VPN restoration.
The lesson from these incidents is not that ZTNA migrations are inherently risky. It is that the risk is concentrated in the application compatibility assessment phase, and that a phased migration sequence distributes that risk across a manageable discovery process rather than exposing it all at once.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report evaluated ZTNA platforms on migration support capability — specifically, the tooling, documentation, and professional services that vendors provide to support phased VPN-to-ZTNA transitions.
Zscaler Private Access received strong marks for its application discovery tooling, which helps organizations identify the on-premises applications in scope before the migration begins. Palo Alto Networks Prisma Access scored well on its migration assessment services, including pre-migration Kerberos and NTLM compatibility analysis. Cloudflare Access was recognized for its lightweight connector architecture, which simplifies on-premises connector deployment for the on-premises application migration phase.
Vendors that scored lower in this category — including some that perform well on core ZTNA capability — had limited documentation for organizations coming from legacy Cisco AnyConnect or Palo Alto GlobalProtect deployments, which remain the two most common VPN platforms in the enterprise.
The migration tooling gap is real. Organizations should specifically ask ZTNA vendors for documentation of their recommended migration sequence and request customer references who have completed full VPN decommissioning — not just ZTNA deployment.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
The phased migration sequence works because it separates the risk of ZTNA deployment from the risk of VPN decommissioning. Here is the sequence, with the common blockers at each phase.
Phase 1 — New Users and Contractors Only
New employees and contractors are provisioned on ZTNA from day one. No VPN credentials are issued. This phase tests ZTNA coverage without touching existing users.
Common blocker: Onboarding workflows that have been built around VPN provisioning. IT teams often have automated VPN credential issuance embedded in their IAM workflows. These need to be disabled for new users before Phase 1 begins.
Phase 2 — Existing Users, Cloud Applications First
Existing employees are moved to ZTNA for cloud applications — Microsoft 365, Salesforce, Workday, and other cloud-hosted applications. VPN remains active for on-premises applications.
Common blocker: SaaS applications that use IP allowlisting. If a SaaS vendor has allowlisted your VPN IP pool, access from ZTNA will fail. This requires contacting the SaaS vendor to update their allowlist or, in some cases, reconfiguring the application's access controls.
Phase 3 — On-Premises Application Migration
Each on-premises application is migrated to ZTNA individually. A ZTNA connector is deployed in the data center or private cloud segment that hosts the application. The application is removed from VPN split-tunnel configuration. Users are tested. VPN access to that application is disabled.
Common blockers:
- IP-based access controls in legacy applications that break when connections arrive from a ZTNA connector IP rather than the VPN pool. This requires modifying the application's network access configuration, which may require vendor involvement.
- Thick-client applications that require VPN for initial installation or licensing validation. These require either a ZTNA connector-compatible approach or a one-time VPN exception during client deployment.
- Kerberos and NTLM authentication flows that require specific domain controller routing through the ZTNA connector. These require connector configuration changes that are not always documented in standard ZTNA setup guides.
- Legacy resources like network printers, file shares, and shared drives. ZTNA connectors handle these with varying degrees of elegance across vendors. File share access via SMB over ZTNA connector is functional but requires careful latency management for users who were previously on LAN.
Phase 4 — VPN Decommissioning
Once every on-premises application has been migrated and validated on ZTNA, VPN can be decommissioned. This phase should only begin after a 30-day parallel operation period during which both VPN and ZTNA are available and ZTNA is the primary path.
The Identity Dependency
ZTNA requires a mature identity provider. Azure AD (Entra ID), Okta, or Ping Identity must be in place with device posture signaling configured before ZTNA can enforce device trust policies. Organizations without MDM or EDR enrollment have a dependency to resolve before ZTNA can enforce anything beyond user identity. ZTNA without device posture is a weaker control than it appears — it authenticates the user but not the device.
Questions Your Buying Team Should Be Asking
1. What application discovery tooling does your platform provide to help us identify the on-premises applications in scope before we begin the migration?
The answer tells you whether the vendor treats migration as a technology deployment or a business change management process. Vendors with mature application discovery tooling understand that most migrations fail because of incomplete app inventories.
2. What is your documented process for handling applications that use IP-based access controls, and have you successfully migrated customers running legacy Kerberos-authenticated applications through your platform?
This question surfaces the vendor's real-world experience with the most common legacy application blockers. Ask for specific examples and customer references.
3. How does your connector architecture handle SMB file share access, and what is the expected latency impact for users who previously accessed file shares on LAN?
File shares are frequently the last on-premises resource to be migrated and the most common source of user experience complaints. Get specific performance data from the vendor.
4. What device posture attributes does your platform evaluate at authentication, and what happens when a device fails posture — session block, step-up authentication, or reduced access?
This question tests the depth of the vendor's device trust implementation. A binary block-or-allow posture policy is less mature than a granular stepped response that can quarantine a non-compliant device from sensitive resources while maintaining access to general productivity applications.
5. Which VPN platforms do you have documented migration paths from, and can you provide a reference customer who has completed full VPN decommissioning — not just ZTNA deployment?
Full decommissioning references are rare and valuable. Most vendors can produce customers who have deployed ZTNA; far fewer can produce customers who have actually turned off VPN entirely. The distinction matters.
The Stackcurve Take
VPN-to-ZTNA migration is a multi-quarter project, not a weekend cutover. The organizations that succeed treat it as an application migration program with a security architecture change as the destination — not a security project that happens to touch applications.
The phased sequence — new users first, cloud apps second, on-premises apps third, VPN decommissioning last — exists because it distributes discovery risk across the migration timeline. Each phase surfaces a class of compatibility issues that would otherwise all appear at once in a big-bang cutover.
The organizations that fail invariably skip Phase 1 or Phase 2 in the interest of project timeline compression. The result is a Phase 3 that is too large to troubleshoot under operational pressure, followed by an emergency rollback.
The vendor you choose matters. But the sequence you follow matters more.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers ZTNA migration support capability, vendor-by-vendor. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.