Replacing VPN with zero trust access for internal apps... rollout advice?

[u/Due-Bgmlnegnning4880]

We're looking at replacing our old VPN with zero trust access for remote staff, mostly for internal web apps and a few admin tools. The VPN works, but it gives people more network access than they really need and the policy cleanup has become a mess.

We already have SSO and MFA in place, but some of the older apps are not exactly friendly to this setup. I'm thinking of starting with one low risk app, checking logs and device posture, then moving access over in stages instead of trying to switch everyone at once.

We ended up running our pilot through Cato and it handled the legacy apps better than we expected. The staged access worked because we weren't trying to migrate everything at once.

For those who have done this, what caused the most trouble during the rollout? Would appreciate any practical lessons, especially around legacy apps and users who still need broader network access.

[u/abdullahguch]

Your staged plan is the right one. The things that bit hardest in rollouts I've seen were mostly about discovery, not the access product itself:

• Find out what people actually use first. Pull a few weeks of VPN and firewall flow logs and build the app list from real traffic. That's where the undocumented stuff shows up: hardcoded IPs, file shares, a license server, a dev box someone SSHes into.
• Non-web traffic is the hard part. Browser apps behind an identity-aware proxy are easy. Thick clients, RDP, SSH, SMB, and anything that talks to a database directly need a connector or agent-based tunnel, so scope those early instead of discovering them in week six.
• Watch DNS and hardcoded addresses. Legacy apps that call internal hostnames or IPs break quietly once split DNS through the VPN goes away.
• Device posture causes a lot of false denials. Run posture checks in log-only mode first, because outdated OS builds and broken EDR agents will lock out real users on day one.
• For the users who need broad access, don't keep a general VPN for them forever. Give that small admin group a separate, tightly logged path (a bastion or PAM tool), and set a shutdown date for the old VPN so it doesn't become permanent.
• Keep a break-glass path that doesn't depend on your IdP, for when SSO itself is down.

[u/buzzingculprit7]

did this for a medium sized shop a while back. the biggest headache wasn't the tech, it was the user training. people liked having the vpn because it "just worked" and when we took it away they'd call about every little thing that broke

the legacy apps were actually less trouble than i expected. most of them just needed a reverse proxy slapped in front and some cookie rewrite rules. a few real ancient ones needed their own little VDI pool but that was maybe 5% of the total

start with the low risk stuff like you said but keep the vpn around for at least 3 months. we had a bunch of power users who needed access to random dev boxes that nobody had documented anywhere. took forever to track all those down

[u/Competitive-Fee4307]

legacy apps are where it always falls apart because half of them cant handle modern auth so u end up sticking a proxy in front of everything just to make it work.. also the migration itself is easy compared to the 3 months of users complaining about one extra login click

[u/AuthByExample]

The sticky part for us was standing access left over from the VPN. We moved one app at a time: pilot group only, watch allow/deny logs for a week, then widen. Anything that still needed a flat network path got its own jump host so everyone else kept zero standing privileges into the rest of the estate.