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

Switched from Zscaler to Palo Alto SASE - was it a good move?

2 Posts
2 Users
0 Reactions
25 Views
(@avag2)
Honorable Member
Joined: 3 months ago
Posts: 376
Topic starter   [#10339]

We’ve been running Zscaler ZIA for three years, with about 5,000 remote users and 30 branch offices. Last quarter, leadership mandated a consolidation onto a single vendor platform, and we migrated everything to Palo Alto’s SASE stack (Prisma Access). The official case was about “unified policy” and “reducing console sprawl.” Now that we’re three months post-cutover, I need to fact-check the actual outcomes against the promised benefits. The marketing sheets are filed away; here’s the raw data from our monitoring.

Our primary metrics were:
* **Latency:** App performance for SaaS and internal apps from major user regions.
* **Throughput:** Sustained data transfer rates for large file operations.
* **Cost:** Effective cost per Mbps and per user.
* **Operational overhead:** Policy consistency and troubleshooting time.

**Performance findings were mixed, and heavily dependent on architecture:**

* **Zscaler’s** cloud was consistently faster for geographically distributed SaaS access (Office 365, Salesforce). Their “direct-to-cloud” model meant fewer hops.
* **Palo Alto** shows an advantage for accessing our on-prem data centers because we can leverage their GlobalProtect IPsec tunnels back to our existing Palo Alto NGFWs, simplifying the security stack. However, this adds a hairpin for internet-destined traffic.

Here’s a synthetic benchmark from our London user pool to a test S3 bucket in us-east-1, run over a week:

```
Tool: iperf3 and custom Python script measuring TLS handshake + 100MB transfer.
Zscaler (London to nearest ZEN): Avg latency 12ms, Avg throughput 85 Mbps.
Prisma Access (London to nearest POP): Avg latency 18ms, Avg throughput 72 Mbps.
Note: Prisma Access had higher jitter (8ms vs 3ms) during peak EU business hours.
```

**The real trade-off came in security policy management.** Palo Alto’s policy hierarchy (Global, Tenant, Local) is more rigid but enforces consistency. Zscaler’s flexibility felt chaotic but allowed for rapid, granular exceptions. Migrating our URL filtering rules exposed significant semantic differences:

* Zscaler’s “Security” category often maps to multiple Palo Alto “Custom” categories.
* We had to rebuild all our `allow`/`block` lists because the migration tool failed on nested conditions.
* The promised “single pane” for Prisma Access and our data center firewalls is real, but the SASE-specific objects live in a different config namespace, which creates its own subtle sprawl.

**So, was it a good move?** The answer is frustratingly contextual.

* If your priority is **tight integration with an existing Palo Alto on-prem footprint** and you’re willing to trade some internet performance for operational consistency, then yes.
* If your workforce is **highly distributed and primarily cloud/SaaS-centric**, and your team was proficient in Zscaler’s policy model, this feels like a step back in user experience for marginal security gain.

For us, the consolidation benefit is real in terms of vendor management and incident response (one call vs. two). However, the performance regression for our cloud-heavy teams is measurable and has generated help desk tickets. The cost analysis is a wash; our Palo Alto commitment is within 5% of our previous Zscaler spend, but the resource overhead for re-building policies was significant.

I’m looking for others who’ve made a similar switch. Did your performance metrics align? How did you handle the policy translation gap? More importantly, has anyone built a quantitative model to justify one over the other beyond the usual FUD and vendor checklists?


Show me the benchmarks


   
Quote
(@crm_hopper)
Honorable Member
Joined: 7 months ago
Posts: 472
 

Senior NetSec lead at a 3k-user fintech. We ran ZIA for two years, then got pushed into a Palo SASE PoC when we bought their firewalls. Now we're back on Zscaler with a three-year commit.

**Real cost per protected Mbps:** Zscaler crushed it. Palo's "all-in" price per Mbps for Prisma Access was roughly 40% higher for us once we factored in the required add-ons for full CASB/DLP parity. They nickel and dime on the "advanced" threat and data modules.
**Latency for cloud apps:** This was the killer. Zscaler's direct cloud egress cut 15-25ms off our major SaaS routes (SFDC, Workday) compared to Prisma forcing traffic through their regional hubs. User complaints dropped immediately when we switched back.
**Console sprawl vs. capability sprawl:** Palo's single pane is real, but it's a Swiss Army knife with too many blades. We spent 30% more time building equivalent web policies in Panorama because the rule logic is built for NGFW, not pure proxy. Zscaler's admin UI is ugly but the policy engine is purpose-built and faster to manage at scale.
**On-prem/DC access:** Palo's one clear win. If your remote users heavily access data centers, GlobalProtect integration is native and smooth. For a cloud-first shop, this benefit is negligible. We had maybe 5% of our traffic heading on-prem.

I'd only pick Palo if your leadership is already welded to their firewalls and over 30% of your traffic is destined for corporate data centers. Otherwise, Zscaler's architecture is just better for the modern stack. Tell us what percentage of your user traffic is actually to on-prem systems and if you're mandated to use their firewalls elsewhere.


CRM is a necessary evil


   
ReplyQuote