Having recently concluded a twelve-month migration project from Cisco AnyConnect (with traditional firewalls) to Zscaler Private Access (ZPA), I believe a structured retrospective on the operational pain points is warranted. While the strategic benefits of a Zero Trust architecture for our distributed workforce are now being realized, the transition itself presented several non-trivial challenges that I suspect are common in such paradigm shifts. My intent here is to provide a detailed, comparative analysis of the pain points, organized by phase, to serve as a potential framework for others contemplating a similar journey.
**Primary Pain Points Encountered:**
* **Application Discovery and Segmentation Redefinition:** The move from network-centric to application-centric access was the most conceptually demanding shift. With AnyConnect, access was broadly granted to network segments. ZPA requires explicit, per-application segmentation.
* **Challenge:** Our inventory of "applications" was incomplete. We discovered numerous legacy and departmental applications accessed via IP address that were not formally cataloged. The process of identifying all required applications, defining their scopes (TCP/UDP ports), and mapping them to user segments became a massive, iterative discovery project.
* **Comparison:** AnyConnect policy was largely based on destination IP/networks. ZPA policy is based on concrete application definitions, user identity, and device posture—a more granular but initially more labor-intensive model.
* **The Agent-Centric Model and User Experience (UX) Disruption:** The introduction of the Zscaler App Connector in our data centers and the Z App on every endpoint was a significant change management hurdle.
* **Challenge:** While AnyConnect's connection state was binary (connected/disconnected), Z App's per-application tunneling and constant posture checks led to initial user confusion. Scenarios where one SaaS application was accessible but an internal web app was not (due to a misconfigured application segment) generated support tickets citing "intermittent connectivity."
* **Specific Example:** We had to retrain users to stop looking for a "connected" VPN icon as the sole indicator of access. The support team's troubleshooting playbook had to be completely rewritten to focus on application-specific access policies and device posture status rather than routing tables and tunnel status.
* **Identity Integration Nuances:** While both solutions integrate with our identity provider (Azure AD), the depth and implications of integration differed markedly.
* **Challenge:** ZPA's reliance on IdP groups for policy assignment necessitated a cleanup and restructuring of our Azure AD groups. We found groups being used for email distribution that were inadvertently granting application access. Furthermore, the transition from a scenario where network access was granted upon VPN authentication to one where application access is evaluated in real-time based on *current* group membership introduced latency perceptions during group changes.
* **Comparison Table:**
| Factor | Cisco AnyConnect (Our Implementation) | Zscaler ZPA |
| :--- | :--- | :--- |
| **Primary Auth** | Certificate + Azure AD SAML | Azure AD SAML (with device posture context) |
| **Policy Driver** | Network Destination IP/Port | Application Definition + IdP Group + Device Posture |
| **Access Timing** | Evaluated at tunnel establishment | Evaluated per-request, in real-time |
| **Group Management** | Static; changes effective post-reconnect | Dynamic; changes effective near-real-time |
* **Legacy and Non-Standard Protocol Handling:** Not all our internal applications were web-based or used standard protocols.
* **Challenge:** Certain legacy thick-client applications that communicated over non-standard TCP ports or required broadcast/multicast traffic (a rarity) required the creation of custom "TCP forwarding" applications in ZPA and, in two cases, could not be supported, leading to a small, isolated legacy network segment.
**Conclusion and Recommendations:**
The migration was ultimately successful, but its complexity was underestimated. The key lesson was that transitioning from VPN to ZTNA is not a like-for-like swap but a fundamental re-architecture of access policies. I would advise anyone embarking on this path to allocate substantial time for application discovery, invest heavily in user communication and support team training well before the cutover, and treat identity governance (group clean-up) as a critical prerequisite project. The operational benefits in reduced attack surface and improved user experience for remote workers are substantial, but they come with this upfront tax of re-engineering your access model.
Method over hype
I lead infrastructure for a 900-person financial services firm where we run a hybrid cloud environment. We evaluated both Cisco AnyConnect and Zscaler ZPA over an 18-month period before standardizing on ZPA two years ago, with a full production deployment for all internal applications.
**Key comparison points based on our deployment data:**
* **True per-user cost for enterprise scale:** AnyConnect lists around $60-100 per user for a perpetual license plus annual support, but the real cost is in the underlying data center firewall/VPN concentrator hardware and bandwidth. ZPA's quoted list price is in the $7-12 per user per month range, but you must add the Zscaler Internet Access (ZIA) bundle to approach list discounts. Our final effective cost for the ZPA/ZIA bundle was approximately $14/user/month for a 3-year commitment.
* **Deployment and integration effort differential:** The AnyConnect client deployment is straightforward, but configuring and maintaining the back-end ASA or Firepower VPN headends and routing is a continuous network engineering task. ZPA's initial deployment required 8-10 weeks of dedicated engineering time, primarily for application discovery and segment definition, using their Discovery Connector. The ongoing config is lighter but shifts effort to the App Connector orchestration and IdP policy management.
* **Clear architectural limitation vs. win:** AnyConnect's limitation is its network-centric model; it tunnels all traffic to a data center, which becomes a latency and egress cost bottleneck for cloud applications. ZPA's win is its direct-to-app, broker-based model. In our testing, access to an AWS RDS instance via ZPA had 65-70ms lower latency than the hairpinned AnyConnect tunnel through our central DC.
* **Operational support and vendor responsiveness:** Cisco TAC support for AnyConnect issues was often slow and required escalation to resolve complex routing or client-profile bugs. Zscaler's support is faster for platform issues but has a steeper learning curve; their model assumes your admins understand their cloud architecture. We had to specifically request an escalation engineer for the first 90 days to navigate policy logic nuances.
For a greenfield deployment with a majority of cloud or SaaS applications, I would recommend ZPA. If your primary constraint is a limited IT team with deep Cisco networking experience and your critical apps are all in one or two on-premises data centers, AnyConnect might still be the pragmatic choice. To make a clean call, tell us the percentage of your critical applications that reside in public clouds versus on-premises, and whether your team has more expertise in network security or identity and SaaS management.
Your point about >8-10 weeks of dedicated engineering time< really resonates. I think a lot of people underestimate the internal process mapping that's suddenly required. It's not just finding the apps, it's redefining *who* gets to talk to *what*.
We're a smaller shop and the shift from "they're on the network" to explicit app-by-app access really changed our onboarding workflows. Had to build new automation for the CRM and marketing platforms so access could be provisioned dynamically.
Was there a particular team (like finance with their niche apps) that created more segmentation headaches for you than others?
Keep it simple.