From Legacy VPN to ZTNA: A Phased Migration Strategy

Why VPN Migration Matters Now

Traditional VPN architectures were designed for a different era. They assumed users worked primarily from offices, applications resided in data centers, and network location could serve as a trust indicator.

None of these assumptions hold today. Remote work is permanent. Applications are distributed across cloud providers. Threat actors exploit the implicit trust VPNs grant once connections are established.

Zero Trust Network Access addresses these architectural limitations while improving both security posture and user experience.

Understanding the Differences

Traditional VPN Characteristics

• Network-level access once authenticated
• Trust established at connection time
• Lateral movement possible within granted network segments
• Typically backhauled through central concentrators
• Binary access model (connected or not)

ZTNA Characteristics

• Application-level access only
• Continuous verification of identity and context
• No lateral movement capability
• Distributed enforcement at the edge
• Granular access based on policy

Migration Planning

Assessment Phase

Before beginning migration, understand your current state:

Inventory VPN usage:

• Which applications are accessed through VPN?
• Who uses VPN and from where?
• What are peak usage patterns?
• What security controls exist post-VPN?

Document dependencies:

• Applications requiring network-level access
• Legacy systems with IP-based authentication
• Non-HTTP protocols in use
• Third-party vendor access patterns

Identify stakeholders:

• IT operations teams managing VPN infrastructure
• Security teams monitoring VPN traffic
• Business units dependent on VPN access
• Executive sponsors for the migration

Application Categorization

Group applications by migration complexity:

Quick Wins:

• Modern web applications with SSO
• SaaS applications accessible via ZTNA
• Applications already using identity-based access

Moderate Effort:

• Legacy web applications requiring connector deployment
• Applications with database dependencies
• Internal APIs and services

Complex:

• Applications requiring network-level access
• Legacy protocols (RDP, SSH to many hosts)
• Applications with IP-based trust relationships
• Third-party dependencies

Phased Migration Approach

Phase 1: Parallel Deployment

Deploy ZTNA infrastructure alongside existing VPN:

1. Implement ZTNA platform and establish connectivity

2. Configure identity provider integration

3. Deploy connectors in data center and cloud environments

4. Onboard 2-3 pilot applications

5. Migrate pilot user group

6. Validate functionality and user experience

Success criteria:

• Pilot users accessing applications without VPN
• No increase in helpdesk tickets
• Performance equal to or better than VPN
• Security logging operational

Phase 2: Accelerated Migration

Expand ZTNA coverage systematically:

1. Prioritize remaining applications by complexity

2. Migrate quick-win applications weekly

3. Address moderate-effort applications

4. Expand user migration in waves

5. Monitor and resolve issues continuously

Key activities:

• Weekly migration sprints
• User communication and training
• Performance monitoring and optimization
• Security policy refinement

Phase 3: VPN Deprecation

Reduce VPN dependency to minimum:

1. Identify remaining VPN-dependent use cases

2. Implement workarounds where possible

3. Establish exception process for unavoidable VPN use

4. Communicate deprecation timeline

5. Begin infrastructure decommissioning

Considerations:

• Maintain VPN for genuine edge cases
• Establish clear criteria for VPN exceptions
• Plan infrastructure retirement
• Document lessons learned

Phase 4: Optimization

Refine and enhance ZTNA deployment:

1. Optimize policies based on operational data

2. Implement advanced features (DLP, CASB integration)

3. Automate onboarding processes

4. Establish continuous improvement practices

Technical Design Workstreams

A successful VPN-to-ZTNA migration is not just a product rollout. It is a set of technical workstreams that replace network-level trust with identity, device posture, application segmentation, and continuous monitoring.

Application Discovery and Dependency Mapping

Start by building an application inventory that is specific enough for migration engineering. A spreadsheet with application names is not enough.

Capture these fields for each application:

• Business owner and technical owner
• User groups, admin groups, and third-party access requirements
• Protocols, ports, and authentication method
• Data sensitivity and compliance requirements
• Current VPN profile, firewall rule, and source network dependency
• Backend dependencies such as databases, file shares, APIs, and jump hosts
• Required DNS names, certificates, and split-horizon resolution behavior
• Peak usage windows and acceptable maintenance periods

Use VPN logs, firewall logs, DNS logs, endpoint telemetry, and SSO reports to validate the inventory. Interview data alone will miss hidden dependencies.

ZTNA Policy Mapping

ZTNA policy should be based on application access, not broad network reachability. Convert legacy VPN groups into explicit access policies.

A practical policy model includes:

• User identity: group membership, role, employment status, and privileged access requirements
• Device posture: managed device, encryption status, EDR health, OS version, patch state, and certificate presence
• Location and risk: impossible travel, risky sign-in, anonymous network, and geo-risk signals
• Application sensitivity: normal business app, administrative app, regulated-data app, or crown-jewel system
• Session controls: re-authentication, step-up MFA, clipboard restrictions, file download controls, and session recording where appropriate

Do not copy VPN access groups directly into ZTNA. VPN groups often contain years of accumulated exceptions. Use the migration as a chance to remove stale access.

Connector and Enforcement Placement

Connector placement determines performance, resilience, and blast radius. Place connectors close to the applications they publish, not simply where the old VPN concentrator lived.

Design considerations:

• Deploy connectors in each major data center, cloud VPC/VNet, or application hosting zone.
• Use multiple connectors per critical site or zone for high availability.
• Avoid routing all ZTNA traffic through one shared connector if it creates a new choke point.
• Separate production, development, management, and third-party access paths where possible.
• Confirm connectors can resolve internal DNS names and reach only the applications they publish.
• Monitor connector CPU, memory, tunnel state, latency, and failed application requests.

A good design limits what a compromised connector path can reach. ZTNA should shrink the accessible network, not rebuild the same flat VPN path through a new product.

Legacy Protocol Handling

Many VPN migrations slow down because of legacy protocols. RDP, SSH, SMB, thick clients, database consoles, and vendor tools often assume network adjacency.

Handle these patterns explicitly:

• Replace broad RDP/SSH access with privileged access workflows or browser-based access where possible.
• Publish specific administrative apps instead of entire management subnets.
• Move file access to managed collaboration platforms or brokered file access patterns.
• For database clients, validate authentication, TLS, DNS, and source restrictions before migration.
• For vendor access, require named accounts, MFA, session recording where possible, and expiration dates.

If a protocol truly requires network-level access, keep it as a documented exception with owner approval, compensating controls, and a target retirement date.

Decommission Criteria

VPN deprecation should be based on evidence, not optimism. Before retiring a VPN profile or concentrator, confirm that business-critical paths have been migrated and monitored through at least one normal business cycle.

Minimum retirement criteria:

• 95 percent or more of normal user sessions no longer require VPN.
• All critical applications have a tested ZTNA path and rollback path.
• Helpdesk ticket volume has returned to baseline after migration waves.
• Security logging, identity logs, and application access logs are visible in SIEM.
• Privileged access and third-party access have documented ZTNA or exception workflows.
• Remaining VPN exceptions have owners, expiration dates, and compensating controls.
• Disaster recovery and emergency administration paths are tested without relying on undocumented VPN access.

When these criteria are met, remove VPN access in stages: disable unused profiles, reduce allowed groups, shut down inactive gateways, then retire infrastructure and firewall rules. Keep a final rollback window, but do not leave unused VPN access available indefinitely.

Managing Risks

Rollback Capability

Maintain VPN access during migration:

• Keep VPN infrastructure operational until Phase 3
• Ensure users can revert if ZTNA issues arise
• Document rollback procedures
• Test rollback process before critical migrations

Communication Strategy

Keep stakeholders informed:

• Regular updates to executive sponsors
• Clear communication to affected users
• IT team briefings on changes
• Success stories to build momentum

Change Management

Minimize disruption:

• Avoid migrations during critical business periods
• Stage changes during low-usage windows
• Provide enhanced support during transitions
• Gather and act on user feedback

Measuring Progress

Track these metrics throughout migration:

• Applications migrated vs. total inventory
• Users migrated to ZTNA-only access
• VPN session volume trending downward
• User satisfaction scores
• Security incidents related to remote access
• Support ticket volume for access issues

Success is measured not just by completion but by improved security posture and user experience.