How to Get Rid of Your VPN: A Step-by-Step Playbook

You've Decided. Now What?

Congratulations — you've accepted that your VPN is a liability, not an asset. That's the hard part. The rest is execution.

This guide isn't about the philosophy of Zero Trust or the theory of SASE. It's the tactical playbook for ripping out your VPN and replacing it with something that actually works. We'll cover the full lifecycle: inventory, prioritize, migrate, validate, decommission.

Step 1: Inventory Everything Behind the VPN

Before you can replace the VPN, you need to know what it's protecting. Most organizations are shocked by what they find.

Build your application inventory: - Pull VPN logs for the last 90 days and identify every unique destination (IP + port) - Map those destinations to applications — many will be obvious (the HR portal on 10.0.5.20:443), some will be mysteries - Categorize each application: web app, thick client, SSH/RDP, file share, database, API - Note the protocol: HTTP/HTTPS, SSH, RDP, SMB, custom TCP/UDP

Document your user base: - How many concurrent VPN users on an average day? Peak day? - Which user groups access which applications? - Are there external users (contractors, partners) on the VPN? - What devices are in play? Managed laptops, BYOD, mobile?

Map your infrastructure: - Where are your VPN concentrators? (Data centers, cloud, both?) - What's the current VPN topology? (Hub-and-spoke, mesh, hybrid?) - Which identity provider(s) are in use? - What's the current MFA situation?

This inventory will take 1-2 weeks for a mid-size organization. Don't skip it. Every surprise you find now is a crisis you prevent later.

Step 2: Categorize and Prioritize

Not all applications are created equal when it comes to migration difficulty. Sort your inventory into buckets:

Easy (migrate first): - Web applications (HTTP/HTTPS) — these can go behind Cloudflare Access with clientless, browser-based access - Any SaaS application currently hairpinned through the VPN - Internal wikis, documentation sites, dashboards

Medium (migrate second): - SSH and RDP access to servers — Cloudflare supports browser-based SSH/RDP rendering - APIs and microservices — route through Cloudflare Tunnel - Applications that need specific DNS resolution

Hard (migrate last): - Thick client applications with custom protocols - Legacy applications that require specific network paths - Anything that uses UDP multicast or broadcast - File shares (SMB/CIFS) with heavy usage

Maybe never: - If you have a truly ancient application that can only work via raw network access, it might stay on a minimal VPN. That's OK. The goal isn't zero VPN — it's VPN for 2% of traffic instead of 100%.

Step 3: Set Up the Foundation

Before migrating your first app, get the infrastructure in place:

Identity Provider Integration: Connect your IdP (Okta, Azure AD, Google Workspace, etc.) to Cloudflare Access. This is the single most important step — every access decision will flow through your IdP.

If you don't have an IdP, stop and fix that first. Cloudflare Access can work with one-time PINs as a fallback, but a proper IdP is non-negotiable for production.

Cloudflare Tunnel: Install the Cloudflare Tunnel connector (cloudflared) on a server in each network where your applications live. This creates an outbound-only connection from your network to Cloudflare's edge — no inbound firewall rules required.

For cloud-hosted apps, deploy cloudflared as a sidecar or on a dedicated instance. For on-premises apps, install it on a VM or container in the same network segment.

Device Posture (Optional but Recommended): If you want to enforce device health (OS version, disk encryption, endpoint protection), deploy the Cloudflare WARP agent to managed devices and configure posture checks. This is optional for the initial migration but valuable for high-security applications.

Step 4: Migrate Application by Application

Pick your first "easy" application and go:

1. Create a Cloudflare Tunnel route from the Tunnel connector to the internal application
2. Create an Access policy that defines who can reach it (e.g., "Engineering team + device posture check")
3. Assign a public hostname (e.g., app.yourcompany.com) or use the Cloudflare Access app launcher
4. Test with a small group — have 5-10 users try the new path while VPN access remains available
5. Collect feedback — the feedback will be overwhelmingly positive because the new path is faster
6. Expand to all authorized users
7. Monitor VPN logs — watch traffic to the old path decline
8. Repeat for the next application

Typical pace: 2-5 applications per week once you've got the pattern down. The first app takes a day. The tenth app takes 30 minutes.

Step 5: Handle the Hard Cases

For thick client applications and custom protocols, you'll need the WARP agent with private network routing:

1. Deploy the WARP agent to devices that need access
2. Configure split tunnel rules to route only specific IP ranges through Cloudflare
3. Set up private network routes in the Cloudflare dashboard
4. Apply Access policies to the private network routes

This gives you the same per-request authorization and logging for non-HTTP traffic, without the performance penalty of a traditional VPN.

Step 6: The Decommission

Once VPN concurrent connections drop below a meaningful threshold (typically <10% of peak):

1. Announce the timeline — give remaining VPN users 30 days notice
2. Identify stragglers — who's still connecting? Why? Migrate their use case or provide an alternative
3. Disable new VPN accounts — no one gets VPN access after this date
4. Set a hard cutoff — turn off the VPN on a specific date
5. Celebrate — you just eliminated one of the most painful pieces of infrastructure in your organization

Step 7: Don't Forget the Cleanup

After decommission: - Revoke all VPN certificates - Remove VPN client software from managed devices - Update security documentation and runbooks - Cancel VPN hardware maintenance contracts - Reclaim data center rack space and power - Update your DR/BC plans - Tell your CFO about the savings

Common Mistakes

Moving too slowly: Analysis paralysis kills migrations. Start with one app and iterate.

Trying to replicate VPN topology: Don't recreate your VPN's subnet-based access model in Cloudflare. Think in terms of applications and identities, not IP ranges.

Skipping the inventory: Surprises during migration are expensive. Spend the time upfront.

Not communicating: Users need to know why things are changing and what to expect. The good news: "it'll be faster and easier" is an easy sell.

The average enterprise completes this process in 3-6 months. Some do it in 6 weeks. None of them regret it.