February 12, 2026Kevin Malmgren6 min read

VPN to ZTNA: 2,000 Users in 90 Days

A deployment war story covering the phases, surprises, and hard-won metrics from replacing a legacy VPN with ZTNA across a 2,000-person organization.

This is a composite case study based on documented VPN-to-ZTNA migrations at mid-sized financial services firms. The scenario: a 2,000-user organization with a seven-year-old Cisco AnyConnect deployment. Helpdesk tickets related to VPN averaged 140 per month. Split-tunnel exceptions had accumulated to the point where the security team could no longer articulate what was actually being inspected. Here is how a migration like this works in 90 days — and what typically almost derails it.

Why we migrated

The trigger was not a security incident. It was a failed audit. The firm's SOC 2 auditor flagged that VPN-connected users had network-level access to segments they had no business reaching. Lateral movement from a compromised VPN session was a realistic scenario, and the compensating controls (network ACLs maintained manually in spreadsheets) were insufficient. The CISO had 90 days to remediate before the next audit cycle.

We evaluated three ZTNA solutions and selected one based on three criteria: agent stability on Windows and macOS, integration with the existing Okta IdP, and the ability to run in monitor mode before enforcing. The vendor choice matters less than the process — what follows applies regardless of which platform you pick.

The four phases

We broke the migration into four phases, each with a distinct goal and a go/no-go gate before the next phase began.

Phase 1: Discovery and baseline (Weeks 1–2)

Before touching any infrastructure, we needed to understand what the VPN was actually being used for. We pulled 30 days of VPN session logs and mapped every destination IP and port to an application owner. The results were sobering.

• 47 unique internal applications accessed via VPN
• 12 of those applications had no documented owner
• 8 applications were accessed by fewer than 3 users each
• Average concurrent VPN sessions: 620 (31% of workforce)
• Peak VPN connection time: 14.2 seconds on Windows, 9.8 seconds on macOS

Phase 2: Parallel deployment (Weeks 3–5)

We deployed the ZTNA agent alongside the existing VPN client to a pilot group of 200 users (10% of the workforce). The ZTNA agent was configured in monitor-only mode — it logged what it would allow or deny, but did not enforce. Users continued to access everything through VPN as before.

This phase revealed three critical issues. First, the ZTNA agent and AnyConnect fought over the DNS resolver on Windows. We had to configure the ZTNA agent to use a local proxy instead of modifying system DNS. Second, seven applications used IP-based authentication (no hostname), which ZTNA cannot broker without a connector reconfiguration. Third, two thick-client applications used non-standard ports that required explicit policy entries.

Phase 3: Cutover by group (Weeks 6–10)

We migrated departments one at a time, starting with IT (who could self-troubleshoot) and ending with the trading floor (who could not tolerate any disruption). For each group the process was identical:

1. Announce the migration date 5 business days in advance via email and Slack
2. Uninstall AnyConnect via endpoint management (Intune) the night before
3. Switch ZTNA agent from monitor to enforce mode at 6 AM local time
4. Staff a dedicated Slack channel with two engineers for the first 48 hours
5. Review ZTNA deny logs daily for the first week and add missing app policies

The IT department cutover went smoothly. Engineering was rougher — they had SSH tunnels and custom scripts that assumed network-level access. We ended up creating a "developer tools" application group in ZTNA that granted broader port access to specific development subnets, with the understanding that this would be tightened in a follow-up phase.

Phase 4: Decommission and measure (Weeks 11–13)

Once all groups were on ZTNA, we kept the VPN concentrators online but unreachable for two weeks as a safety net. No one asked for them. We decommissioned the hardware on day 85.

The numbers

Three months after cutover, the results were unambiguous.

What we would do differently

• Start application discovery earlier — 30 days of log analysis was not enough. 60 days would have caught monthly batch jobs we missed.
• Negotiate the AnyConnect uninstall timeline with the endpoint team before the project starts, not during Phase 2.
• Create a self-service portal for application owners to request ZTNA policies instead of routing everything through the security team.
• Run a tabletop exercise with the SOC before cutover to ensure they knew how to investigate incidents in the new ZTNA logs.

Bottom line

VPN-to-ZTNA migration is not a technology problem. The ZTNA platforms all work. It is an organizational problem: mapping applications, coordinating teams, managing change, and communicating with users. If you get the process right, the technology follows. Ninety days is aggressive but achievable if you have executive sponsorship and are willing to run phases in parallel where the risk is low.

Sources

• NIST, "Zero Trust Architecture" SP 800-207 (2020) — nist.gov
• CISA, "Zero Trust Maturity Model" Version 2.0 (2023) — cisa.gov
• Gartner, "Market Guide for Zero Trust Network AccessZero Trust Network Access" (2023) — gartner.com
• Palo Alto Networks, "What Is ZTNA (Zero Trust Network AccessZero Trust Network Access)?" — paloaltonetworks.com
• Cloudflare, "What is ZTNA?" — cloudflare.com/learning

Related on sase.cloud

One email per publish. Unsubscribe anytime.