Skip to content
Switched from Cisco...
 
Notifications
Clear all

Switched from Cisco AnyConnect to Zscaler ZPA - migration pain points

4 Posts
4 Users
0 Reactions
3 Views
(@revenue_ops_analyst)
Eminent Member
Joined: 2 months ago
Posts: 12
Topic starter   [#2352]

We just completed a full cutover from Cisco AnyConnect to Zscaler ZPA for our remote workforce. The technical win for Zero Trust is clear, but the migration process had several unexpected friction points that I haven't seen discussed much.

The biggest issues weren't with the core ZPA architecture, but with the shift in operational mindset and endpoint reality.

* **Application Segmentation vs. Old Habits:** Defining every application segment felt like building a new CRM from scratch. With AnyConnect, it was just network on/off. With ZPA, we had to audit every legacy tool to define precise access. Several departments didn't even know what URLs or ports their "critical" apps used.
* **The "Agent is King" Reality:** ZPA's strength is its context-aware agent. This became a massive endpoint management headache. Inconsistent OS versions, conflicting security software, and user-admin permissions blocked a smooth rollout. Our pilot group of 50 had 12 different agent-related failure modes.
* **Silent VPN Kill:** We ran a parallel period, but AnyConnect had to be fully removed for ZPA to handle all traffic. Residual Cisco VPN profiles and old DNS configurations caused persistent routing conflicts for about 5% of users.

From a RevOps lens, the user experience impact on sales and support teams during the transition was tangible. We saw a 15% dip in CRM usage metrics for two days because of misconfigured access to Salesforce and our CPQ tool.

For those who have made this switch:
* What was your most effective method for discovering and defining private applications?
* How did you handle the endpoint hygiene prerequisite at scale?
* Did you find the ZPA App Connector deployment more or less burdensome than maintaining traditional VPN concentrators?



   
Quote
(@martech_hoarder)
Trusted Member
Joined: 3 months ago
Posts: 47
 

Hey OP, I've done this exact migration twice now - once at a 1k-person SaaS shop and currently at a 300-person e-commerce company where we run ZPA in prod. You've hit the nail on the head with the operational mindset shift. It's a different game.

My breakdown on the real differences:

* **Deployment Effort:** AnyConnect is a straightforward network tunnel, maybe 40 hours from zero to full deployment for most orgs. ZPA is a 3-6 month project for the same size. You identified the big one: the application inventory. You're not just deploying a tool, you're documenting every single internal app, its dependencies, and user groups. That's 80% of the work.
* **Real Pricing:** AnyConnect is basically a bundled cost if you're already a Cisco shop, maybe $5-10/user/year for just the client. ZPA is a full subscription. List price starts around $8-12/user/month for the core ZPA module, but you'll almost certainly need ZIA (internet access) too, so budget for the Zscaler Platform bundle. It's a significant OpEx shift.
* **Where ZPA Wins:** Once it's built, the security and user experience for approved apps is fantastic. No more hairpinning traffic through a data center. Direct-to-app performance is tangible, and the attack surface shrinks dramatically. It's not just marketing; the zero-trust model works.
* **Where It Breaks:** Legacy and undocumented applications. That random reporting tool from 2012 that needs three odd ports? It'll break. Also, the agent is indeed king. If your endpoint management is weak, this will expose it. You need a solid software deployment and update process, or you'll have a 10% failure rate on agent updates.

My pick is ZPA, but only if you have the internal bandwidth for that 6-month discovery and build phase and your app landscape isn't a complete mystery. If you're in a highly regulated industry or have a mature IT org, it's the way to go.

If you're a smaller team with a lot of legacy tech debt, tell us: 1) how many internal apps you truly have, and 2) how strong your endpoint management is. That'll make the call clean.


one stack at a time


   
ReplyQuote
(@devops_rookie_22)
Reputable Member
Joined: 4 months ago
Posts: 157
 

That point about auditing legacy tools really hits home. We're just starting our cloud migration and even finding the correct ports for some of our old apps has been a nightmare. I can't imagine doing that for the *entire* company at once.

The agent headache scares me too. If you had to do it again, would you push for a stricter OS baseline *before* starting the ZPA rollout, or just accept that the pilot is going to uncover those 12 failure modes no matter what?



   
ReplyQuote
(@pipeline_newbie_lead)
Eminent Member
Joined: 3 months ago
Posts: 13
 

That's a good question about the OS baseline. From what I've seen, the pilot will always find weird edge cases, no matter how strict you are upfront.

We had a standard Windows 10 image, but still ran into a conflict with an old VPN client's network driver that wouldn't uninstall cleanly. It was blocking the ZPA service. So maybe the goal isn't a perfect baseline, but just making sure you have a solid, fast process to fix those 12 failure modes when they pop up.

What's your plan for handling those endpoint exceptions when you find them?



   
ReplyQuote