How to Migrate from VPN to ZTNA: A Six-Step Plan for Mid-Market Teams

Most guides to replacing a VPN with ZTNA describe an architecture. That is not the hard part. The hard part is that your VPN has been running for eleven years and nobody has a complete list of what crosses it.

This is a sequence rather than an argument: six steps, with the inputs each one needs, the artefact it produces, how long it actually takes, and the specific way it goes wrong. Where the published evidence gives a duration, it is quoted. Where it does not, that is said plainly rather than filled in with a number that would look tidier.

One figure sets expectations before anything else. For a mid-market organisation of 100 to 250 users, industry benchmarks put a complete VPN-to-ZTNA replacement at twelve to sixteen weeks of elapsed time, with sixty to seventy per cent of the effort spent on discovery and identity work before a single user notices anything. Cloud-native organisations under fifty seats complete it in four to six weeks. When Indeed replaced remote access for more than 13,000 employees and contractors, the elapsed timeline was a little over three months.

If you have been told this is a fortnight’s work, that is the number to push back with.

Why the sequence matters more than the platform

A remote access VPN puts an endpoint on the network. It authenticates once at the edge, hands out a routable internal address, and from that point the user has network-level reachability across internal subnets, bounded only by internal firewall rules and access lists that almost nobody has revisited since they were written.

ZTNA removes the network step. Instead of placing a device on the network, it brokers an identity- and context-aware session between an authenticated user and one specific application. Internal applications are not reachable from the internet at all; connectors sitting next to the workloads establish outbound-only tunnels to a broker, so there is no inbound listener to scan for.

That difference is why the migration is not a product swap. Everything that quietly depended on network-level reachability has to be found first and re-expressed as an application. If you skip the finding, the re-expressing happens at nine in the morning on cutover day, in front of everybody.

The six steps

Step	Output artefact	Realistic duration	How it fails
1. Passive traffic discovery	Application dependency matrix	3 to 4 weeks	Monitoring window too short to catch monthly jobs
2. Identity modernisation	Clean group structure, SSO federation, phishing-resistant MFA, device posture baseline	2 to 4 weeks	Legacy AD groups migrated as-is, recreating flat trust
3. Connector deployment and web publication	Redundant outbound-only connectors per segment; internal web apps published	1 to 2 weeks	Outbound 443 blocked or symmetric NAT breaking connector sessions
4. Pilot cohort and policy calibration	Validated context-aware policies, split-DNS config, service desk runbook	2 to 3 weeks	Wrong cohort first; edge cases become political problems
5. Departmental cutover and parallel run	Per-department sign-off, falling VPN session count, latency and auth dashboards	4 to 8 weeks	Users silently reverting to the VPN, masking policy defects
6. Decommissioning and archival	Decommissioning record, external scan proving ports closed, audit evidence pack	1 to 2 weeks	Tearing down shared crypto bindings and killing site-to-site tunnels

Durations sourced from published mid-market migration benchmarks and vendor case studies from 2025 and 2026. They describe elapsed time on a typical 100 to 250 user estate, not effort hours.

Step 1: find out what the VPN is actually carrying

Correlate four sources, because no single one sees everything. Firewall and concentrator syslog filtered to the remote client address pool gives you the basic tuple: identity, source virtual IP, destination, port, protocol, volume. NetFlow or IPFIX collectors on core layer-3 switches catch the east-west traffic that never crosses a perimeter and therefore never appears in firewall logs. Debug query logging on internal DNS servers reveals dependencies on short hostnames and internal aliases you had forgotten existed. Endpoint protection and device management telemetry ties active sockets to the processes that opened them, which is how you identify custom client-server applications nobody documented.

The output is an application dependency matrix: destination FQDNs, internal subnets, protocols, ports, user groups, session concurrency, peak bandwidth, classification.

Run it for at least one complete monthly business cycle. Three to four weeks is the sourced range, and the reason is not thoroughness for its own sake: month-end batch jobs, payroll runs and scheduled vendor maintenance connections only appear once.

What routinely surprises people:

• Backup agents on laptops that start multi-gigabyte block-level synchronisation over SMB the moment a tunnel comes up.
• Management consoles that need server-initiated bidirectional communication to push patches or query inventory, which breaks the moment access becomes user-initiated only.
• Printing and scanning: remote staff connecting to office printers on TCP 9100 or 515, and multifunction devices pushing scans directly to endpoint addresses.
• Dynamic RPC applications that handshake on TCP 135 and then negotiate ephemeral high ports, which no static policy will cover.
• The concentrator as a transit router, where remote users reach a second site or a partner extranet through site-to-site tunnels terminating on the same box. This one determines step 6.

Step 2: identity is the actual prerequisite

ZTNA does not inspect network boundaries. It acts as a policy enforcement point executing decisions made against identity context. If the identity provider is full of stale accounts, shared administrative logins and nested groups nobody understands, the ZTNA deployment inherits every one of those problems and gives them a new interface.

NIST SP 800-207 is explicit that access is granted per session, with rules determined dynamically from identity, role, credentials and environmental context, and that authentication and authorisation are enforced before access is permitted. The CISA Zero Trust Maturity Model, version 2.0, sets out what moving beyond the traditional state requires in the identity pillar: deprecating static passwords and legacy authentication, centralising federation, automating user lifecycle through SCIM, and enforcing phishing-resistant MFA for internal and external users alike.

Five things need to be true before step 3 is worth starting:

1. Directory hygiene. Dormant accounts purged, contractor logins linked to a real owner, shared administrative accounts eliminated, and SCIM provisioning connected to the HR system so that revocation is automatic rather than remembered.
2. Groups that mean something. Deeply nested inherited groups replaced with explicit role- and attribute-based groups mapped to application entitlements. A group named after a department is not an entitlement.
3. Phishing-resistant MFA. FIDO2 and WebAuthn factors, with SMS codes, voice calls and standard push notifications blocked at the identity provider, because all three are defeated by adversary-in-the-middle proxies and MFA fatigue.
4. Conditional access. Policies evaluating user risk, impossible travel, IP reputation and time of day before a token is issued.
5. Device posture. Endpoint management and endpoint protection platforms feeding signals into the policy engine: patch level, disk encryption, local firewall state, agent health.

Two to four weeks, scaling directly with how much directory debt you have accumulated. This is the step teams try to skip and the one that determines whether the rest works.

Step 3: connectors and the easy applications

Deploy redundant outbound-only connectors into each internal network segment or VPC, then publish the internal web applications. Web is the low-difficulty category: a ZTNA platform acts as a reverse proxy, connectors pull the application through an outbound TLS session, and identity claims are injected as headers so single sign-on works without touching the backend.

One to two weeks. The failure mode is environmental rather than conceptual: connectors placed behind restrictive stateful firewalls or symmetric NAT without persistent outbound 443 permitted, which produces intermittent disconnects and broker timeouts that look like platform faults and are not.

Step 4: pilot with the right people, in the right order

Three phases, in this sequence, for a reason.

Weeks 1 to 2, IT operations and security engineering. People who understand DNS behaviour, certificate chains and transport diagnostics, and who will describe a problem accurately rather than reporting that the internet is broken. They validate connector stability, latency overhead and private DNS resolution.

Weeks 3 to 4, developers and DevOps. Heavy users of non-HTTP protocols: Git over SSH, database tooling, container management. They find the micro-tunnel and terminal persistence problems.

Weeks 5 to 6, business unit champions. Administrative, HR and sales users on core ERP and CRM. They validate the thing the first two groups cannot: whether it is pleasant to use.

Deliberately excluded from early phases: executive leadership, board members, and the finance team during a monthly close. Not because their time matters less, but because an edge case encountered by an executive in week two becomes a political problem that stalls the project for a month.

Step 5: the parallel run, and stopping people falling back

Four to eight weeks, and this is where most of the elapsed time goes.

The central problem is behavioural. A user who hits any friction on the ZTNA client will disconnect and launch the VPN, because it still works. That single habit masks every configuration defect you needed to find and makes your migration metrics meaningless. Two controls prevent it, and both are firewall work rather than platform configuration.

Suppress egress from the legacy pool. As each application is validated on ZTNA, update perimeter and internal access lists to block traffic to that application’s subnet from the legacy VPN client address pool. The application becomes unreachable over the old path.

Remove the routes. Update the routing table the concentrator pushes to clients, dropping the specific host or subnet routes for migrated applications so traffic is not offered the old tunnel in the first place.

Roll back only against defined numbers, never against sentiment. Three quantitative triggers are worth writing into the plan before you start: broker-induced round-trip latency above 250 milliseconds sustained over a fifteen-minute window; identity provider token validation failures above two per cent of authorisation attempts; or database record lock drops in a core line-of-business application. Anything else is a defect to fix, not a reason to stop.

Step 6: decommission without killing your branch connectivity

This is the step no published guide covers, and it is the one that can take down production.

On a mid-market edge appliance, the same box usually terminates both remote-access client tunnels and the site-to-site IPsec tunnels connecting your branches. Removing one without disturbing the other requires a specific order:

1. Audit the bindings first. Verify that the IKE proposals, Diffie-Hellman groups and pre-shared keys or certificates used by site-to-site tunnels are genuinely separate from the dial-up profiles. Where they share objects, split them before touching anything.
2. De-allocate the client pools. Remove the virtual IP pools, DHCP scopes and authentication realms belonging to dial-up users.
3. Shut down the listener. Administratively disable the SSL VPN portal service or dial-up IPsec daemon bound to the WAN interface.
4. Delete the inbound rules. Remove external-to-internal policies permitting inbound 443 where it was dedicated to the portal, UDP 500 and 4500 for dial-up IPsec, and UDP 1194 where OpenVPN was in use.
5. Prove it from outside. Run external port scans against every public address you own and confirm no remote access daemon answers. This scan output is the evidence, not the intention.
6. Remove the clients. Push silent uninstall of the legacy VPN software through device management, which also removes a network filter driver that would otherwise sit in the stack forever.

Which applications go easily, and which stall the project

Category	ZTNA equivalent	Difficulty	Common blocker
Internal web applications	Reverse-proxy broker with identity claims injected as headers	Low	Hardcoded internal IPs in application code; NTLM instead of modern identity
Thick client and client-server	Agent-based local proxy on a synthetic address; explicit port forwarding	Medium to high	Dynamic RPC ephemeral ports; sensitivity to latency and handshake jitter
SSH and RDP administration	Identity-aware bastion proxy, ephemeral certificates, or browser-isolated streaming	Low to medium	Resistance to session timeouts and clipboard restrictions; credential vault sync
SMB and CIFS file shares	Micro-tunnel to the service FQDN, web file portal, or migration to cloud storage	High. The main stall reason.	Protocol chattiness over latency; short hostname resolution; Kerberos SPN mismatches
Voice and video	Local breakout via secure web gateway split tunnelling, or cloud UCaaS	High	Proxy architectures handle symmetric UDP RTP poorly; jitter and asymmetric routing
IoT, OT and unmanageable devices	Network-level microsegmentation, hardware gateways, browser-isolated jump hosts	Very high	No agent possible; non-routable industrial protocols such as Modbus and BACnet
Contractors and third parties	Clientless browser-based access with web application isolation	Low to medium	Refusal to install corporate agents on non-corporate hardware

The SMB row deserves its own paragraph because it is the single most common reason these projects stop. SMB is a chatty protocol built for a local network: synchronous metadata requests, sequential lock negotiation, constant round trips. Put it through an application proxy over an internet path and performance does not degrade gracefully, it collapses. Users see frozen file explorers, failed saves and mapped drives dropping. Worse, SMB depends on Kerberos tied to Active Directory service principal names, so if the platform alters the destination FQDN or routes through synthetic addresses, ticket exchange fails outright.

Teams that get past this do not solve SMB. They move around it, by relocating collaboration data to cloud document storage or publishing files through a browser portal, and accepting that a small number of genuine file-server dependencies keep a narrow tunnel.

Where these projects actually stall

Beyond SMB, four failure patterns recur.

Split-horizon DNS. ZTNA agents intercept DNS for authorised private namespaces and redirect them to synthetic non-routable addresses to force traffic into the tunnel. Where an organisation has disjointed DNS search suffixes, or users type short hostnames rather than fully qualified ones, the name resolution policy rules do not catch the query. It leaks to public DNS, returns NXDOMAIN, and the application appears broken for reasons that have nothing to do with access policy.

Source IP churn. Some platforms establish an independent micro-tunnel per application request, so the client’s apparent source address changes on the backend. Internal tools, load balancers and databases configured with strict source-IP session affinity read that as session hijacking and start dropping connections or locking accounts.

Driver collisions. Corporate endpoints already run several kernel-level network filter drivers: endpoint protection, data loss prevention, web filtering, the legacy VPN adapter itself. Adding another virtual adapter is a well-documented source of blue screens and broken TCP stacks. Test the full stack, not the platform in isolation.

Exception sprawl. A senior stakeholder hits friction, an exemption is granted, and over eighteen months the exemptions accumulate until posture checks and MFA requirements are bypassed for exactly the accounts most worth attacking. This is a governance failure rather than a technical one, which is why the rollback triggers above are numeric: they give you something to point at that is not an opinion.

We have written more on this pattern in where mid-market SASE migrations actually stall and ten common ZTNA mistakes.

What the auditor wants to see afterwards

For EU organisations this migration is not only a security improvement, it is evidence for an obligation you already have.

NIS2 Article 21(2)(i) requires policies on access control and asset management; Article 21(2)(j) requires multi-factor or continuous authentication and secured communications. A flat VPN extends unsegmented implicit trust on a single authentication event, which is difficult to defend against either.

Under DORA, Article 9(4) and the associated regulatory technical standards require least privilege, strong authentication, continuous monitoring of privileged sessions, tamper-evident audit logs of access decisions, and formal auditable processes for decommissioning outdated ICT systems. That last clause is why step 6 produces a document rather than just a result.

In Belgium, CyberFundamentals is the CCB’s conformity framework for NIS2, and its audit method works in two layers: a documentation layer proving controls are intentionally governed, and an implementation layer proving they actually run. For a remote access migration that means both the zero trust access policy and the exported configurations, log streams and posture checks that demonstrate it in production. In-scope entities were required to have measures equivalent to CyFun Level Basic in place by 18 April 2026, so for most Belgian organisations this is now evidence to maintain rather than a deadline to meet.

The case for keeping the VPN

A network engineer with a small team and no budget will say the VPN works, it is understood, the concentrator is patched, MFA is in front of it, and this whole exercise is three months of effort to solve a problem that has not happened. That deserves a straight answer rather than a slogan.

Two parts of it are right. If your concentrator is current, your MFA is phishing-resistant and your internal segmentation is genuinely enforced, your risk is far lower than the average and the urgency argument does not apply to you. And the effort estimate is real: twelve to sixteen weeks is not a marketing number, it is what the benchmarks say.

What the argument does not cover is the two forcing functions that are arriving anyway. Vendors are removing the feature: Fortinet has already dropped SSL VPN from its smaller appliances and replaced tunnel mode with IPsec across the range, and it is not alone. And the audit expectation has moved from “is remote access controlled” to “show me the per-session authorisation decisions”. Both of those turn a project you could schedule into one that gets scheduled for you.

The honest framing is not VPN versus ZTNA in the abstract. It is whether you do this work on a plan or under a deadline.

Starting this properly

Start with step 1 and nothing else. Turn on the four telemetry sources, let them run for a full month, and build the dependency matrix. You will learn more about your own network in four weeks than in any vendor evaluation, and the matrix is the input to every other decision, including which platform actually suits what you found.

Jimber’s platform is built for mid-market teams doing exactly this: ZTNA and network isolation with clientless browser-based access for contractors, secure web gateway, firewall-as-a-service and web application isolation on one EU-sovereign platform, so the migration adds one system rather than four. If you want a second pair of eyes on your dependency matrix once it exists, book a demo or get in touch. For the architectural comparison first, IPsec VPN versus ZTNA sets out which path suits which estate, and third-party access without a VPN covers the contractor case specifically.

Frequently asked questions

How long does a VPN to ZTNA migration take?

For a mid-market organisation of 100 to 250 users, published benchmarks put a complete replacement at twelve to sixteen weeks elapsed. Cloud-native organisations under fifty seats complete it in four to six weeks. Sixty to seventy per cent of the effort is discovery and identity work before any user-facing change happens.

What is the first step in migrating from VPN to ZTNA?

Passive traffic discovery. Correlate VPN concentrator syslog, NetFlow from core switches, internal DNS debug logs and endpoint telemetry to build an application dependency matrix. Run it across a full monthly business cycle, three to four weeks, so month-end batch jobs and scheduled vendor connections appear.

Can I run VPN and ZTNA at the same time?

Yes, and you should. A parallel run of four to eight weeks is standard for a departmental cutover. The risk is users reverting to the VPN when they hit friction, which hides policy defects. Block the migrated application subnets from the legacy VPN address pool and remove those routes from the concentrator.

Why do ZTNA migrations fail on file shares?

SMB is a chatty protocol designed for local networks, with synchronous metadata requests and sequential lock negotiation. Routed through an application proxy over internet latency, performance collapses and mapped drives disconnect. Kerberos service principal name mismatches compound it when the platform alters destination FQDNs.

What do I do about devices that cannot run an agent?

IoT, OT and industrial devices cannot be brokered through software connectors. Isolate them in dedicated micro-segmented enclaves and expose them to maintenance technicians through browser-isolated jump hosts or hardware gateways. Treat this as a separate workstream from the user migration; it has a different timeline.

When should I roll back a ZTNA cutover?

Define numeric triggers before you start. Reasonable thresholds are broker-induced latency above 250 milliseconds sustained over fifteen minutes, identity provider token validation failures above two per cent of attempts, or record lock drops in a core line-of-business application. Anything else is a defect to fix, not a reason to revert.

How do I decommission a VPN without breaking site-to-site tunnels?

Audit the cryptographic bindings first to confirm the site-to-site IKE proposals and keys are separate from the dial-up profiles. Then de-allocate client IP pools, shut down the portal listener, delete the inbound rules for 443, UDP 500, 4500 and 1194, and verify with an external port scan.

What identity work has to happen before ZTNA?

Five things: purge dormant and shared accounts with SCIM provisioning from the HR system, replace nested legacy groups with explicit entitlement-based groups, enforce phishing-resistant MFA and block SMS and push, add conditional access on risk and context, and feed device posture signals into the policy engine.

Who should be in the ZTNA pilot group?

IT operations and security engineering first, for two weeks, then developers for two weeks, then business unit champions. Exclude executives, board members and finance during a monthly close from early phases: an edge case in front of the wrong audience becomes a political problem rather than a bug report.

Does ZTNA satisfy NIS2 access control requirements?

It provides the technical evidence for Article 21(2)(i) on access control and 21(2)(j) on multi-factor or continuous authentication, but the obligation is broader than any product. In Belgium, CyFun audits in two layers: approved policy documents and exported configurations, logs and posture checks proving the controls run in production.