How to Migrate from VPN to Zero Trust (Without Losing Your Mind)

The Phased Approach

The biggest misconception about moving to Zero Trust is that it requires a "big bang" migration — rip out the VPN on Friday, deploy ZTNA on Monday, pray on Tuesday. That's not how this works.

The smartest organizations run VPN and Zero Trust side by side, migrating applications and users gradually. Here's the playbook.

Phase 1: Pick Your Worst VPN Pain Point (Week 1-2)

Every organization has one app that generates the most VPN complaints. Usually it's: - The internal wiki or documentation site - The HR portal - A project management tool - The company intranet

This is your pilot application. It should be: - Web-based (so it works with clientless access) - Broadly used (so the improvement is visible) - Low-risk (so mistakes don't cause outages)

Action: Set up Cloudflare Access, configure your identity provider, and publish this application. Takes 1-2 hours for a simple web app.

Phase 2: Run Both in Parallel (Week 2-4)

Don't turn off VPN access to the pilot app. Instead, give users a choice: they can access it through the VPN as before, or through the new Cloudflare Access URL.

Send a short email: "You can now access [App Name] directly at [URL] without the VPN. Try it and let us know what you think."

What you'll observe: - Users who try the direct access never go back to VPN for that app - VPN traffic for that app drops within days - Help desk tickets related to that app drop to near zero - Users start asking "can we do this for other apps too?"

Phase 3: Expand to More Apps (Week 4-8)

Ride the momentum. Add the next 3-5 most-used applications to Cloudflare Access. Prioritize based on: - Number of VPN-related complaints - Number of users - Business criticality

For non-web applications (SSH, RDP, thick clients), you'll use Cloudflare's WARP client — but only for those specific protocols. The key difference from VPN: the WARP client routes only the traffic that needs it, not everything.

Phase 4: Enable Advanced Security (Week 8-12)

Now that applications are behind Cloudflare Access, enable the features that VPNs can't match: - Device posture checks: Require disk encryption, OS updates, and endpoint protection - Session duration policies: Force re-authentication for sensitive applications - Geographic restrictions: Limit access from high-risk countries - Browser isolation: Render risky web content in Cloudflare's cloud, not on user devices

Phase 5: Decommission the VPN (Week 12+)

By now, most of your traffic has migrated. The VPN is handling a shrinking trickle of legacy applications. For each remaining app: - Can it be published through Cloudflare Tunnel? (Usually yes) - Does it require a specific network path? (Cloudflare WARP + private routing) - Is it truly un-migratable? (Rare, but keep the VPN for just these apps)

When VPN concurrent connections drop below your maintenance threshold, it's time to turn it off.

Common Objections (and Responses)

"We can't afford the disruption." You're not disrupting anything. The VPN stays on during the entire migration. Users gain a new option; they don't lose the old one.

"Our legacy apps won't work." Cloudflare Tunnel supports TCP and UDP traffic, not just HTTP. If it works over a VPN, it can work over Cloudflare Tunnel.

"We don't have the staff." Cloudflare Access is dramatically simpler to manage than a VPN. Your team will spend less time on access infrastructure after migration, not more.

"What about compliance?" Cloudflare's logging and policy controls are more granular than VPN. You'll be in a stronger compliance position after migration.

The Timeline

Most organizations can complete the migration in 3-6 months. Not because the technology takes that long, but because organizational change takes time. The technology part? The first app goes live in an afternoon.