Anyone successfully replaced their VPN with Banyan in a 300-user company?

We're actually migrating from OpenVPN to Banyan right now, around 180 users so far. It's been smoother than I expected for most SaaS and AWS services.

> How's the on-call overhead compared to maintaining VPN servers?
Huge reduction. No more patching VPN boxes or dealing with cert expiry tickets. The main overhead now is just onboarding new services into Banyan's policy framework, which feels more like configuration than firefighting.

Did you keep any legacy VPN? We have a tiny OpenVPN instance running for one legacy on-prem file server that can't support the Banyan connector. Planning to retire it next quarter.

For a 250-user, all-remote setup like yours, I think you'd see a net decrease in team workload after the initial hump. Curious, are you looking at their Zero-Trust Private Access or the device trust piece? That's where we hit a few user complaints about device enrollment.

We migrated about 200 users from a mesh of IPSec tunnels and OpenVPN to Banyan last year. The initial policy setup for your on-prem K8s and AWS services will take some time, but after that, the on-call alerts practically vanished. No more 2 AM VPN server reboots.

You'll get some user complaints about the new client, especially from folks who liked having a constant "connected" status light. A quick training session on the zero-trust model (access only when you need it) usually clears it up.

For your stack, the Jenkins and GitHub Actions integration is solid. The uptime's been great for us, honestly better than our old VPN. Just make sure you phase the rollout by team.

You've nailed a key point that often gets overlooked in these migrations - the shift from constant connection status to on-demand access really is a cultural change for users. It's interesting, we found the same complaints initially, but that "connected" light was often giving a false sense of security anyway.

Phasing the rollout by team is such wise advice. We took a similar approach and used each team's transition as a mini-pilot to refine our internal documentation and training for the next one. It turned a potential support nightmare into a manageable, iterative process.

Your experience with on-call alerts vanishing matches what I've heard from others. Once you're past that initial configuration hump, the operational quiet is almost startling. It really does free the team up for more interesting work than VPN maintenance.

The "connected light" being a false sense of security is spot on. Our VPN uptime dashboard was green while half the routes were broken. Users just didn't know until they needed something.

Phasing by team is the only way. We started with the platform engineering group. Their feedback let us script the connector deployment for the on-prem K8s clusters before hitting the less technical teams.

The operational quiet is real, but monitor your policy denials. That log is your new "connection status." A sudden spike means a deployment broke a service tag or someone's trying to access something they shouldn't.

We migrated 300 users from a complex Palo Alto GlobalProtect setup to Banyan about 18 months ago, so yes, it can absolutely be done at your scale.

You mentioned uptime and not creating more work. The big trade-off is upfront policy work versus ongoing maintenance. Your team will spend a solid few weeks mapping your on-prem K8s and AWS services into Banyan's trust scoring and access tiers. That's the hump. After that, the day-to-day overhead disappears. We went from about 15-20 monthly VPN related tickets (cert issues, client reconfigurations, subnet conflicts) to maybe two or three about the Banyan client itself.

One specific tip: for the transition complaints, we created a one-page "cheat sheet" contrasting the old and new mental models. The biggest friction wasn't technical, it was users not understanding why they couldn't "see" the internal network until they opened an app. Framing it as "your access is now always with you, but only activates when needed" helped a lot. And we did keep a legacy VPN for one ancient HVAC control system for about six months until we could replace it.

That "cheat sheet" idea is clever. Did you find it helped more with technical staff or the general user base? I can see both groups getting stuck on the old VPN mindset.

The drop from 15-20 monthly tickets to just a few is a huge selling point for my team. We're tired of the certificate hamster wheel. How did you handle training for the initial policy mapping phase? Was it a steep learning curve for the people doing the config work, or did Banyan's model click pretty quickly?

Yes, the "no more 2 AM reboots" part is so real. We had the same experience moving off our old Cisco setup.

That initial policy setup was the major project, but it's a different kind of work. It's building a declarative system instead of constantly troubleshooting a reactive one. Once it's set, it just... works.

Your point about the "connected" light is spot on, but we found some teams, like finance, needed a bit more hand-holding. We ended up creating little status dashboards for their specific critical services within Banyan's console to give them that visual reassurance. It's still on-demand access, but it helped bridge the mental gap.

The dashboard hand-holding for finance is just recreating the same problem. A "reassuring" dashboard for one team snowballs into dashboards for everyone. Then you're back to maintaining status pages instead of fixing the trust issue.

Declarative config is good. But the upfront work they're calling a "major project" is the vendor's pricing model. You're just swapping the work of patching VPN boxes for the work of modeling your entire infrastructure into their proprietary system. Which one actually locks you in harder?

We made the jump last year with about 280 people. The on-call overhead drop was massive for us too - no more VPN server issues. But the policy setup for your on-prem K8s is a real project, like others said. It's a different kind of work though, more like IaC.

User complaints were mostly about the "always on" feeling disappearing. We had a few teams who needed extra reassurance. I actually built a super simple Grafana dashboard showing successful access logs to our main internal apps. It's not a status light, but it helped people see it was working. Might be a middle ground.

Did you keep a legacy VPN? We have one tiny OpenVPN box for a weird legacy database that's getting phased out next month. It's been fine.

Your stack looks perfect for it. The Jenkins integration is really smooth.