Hello everyone. I've been following the migration stories here with great interest, and wanted to contribute a detailed, structured report from our own recent journey. We completed a full production migration from Zscaler Internet Access (ZIA) to Netskope's Secure Web Gateway and Cloud Firewall components approximately six months ago. The primary technical driver was the promise of deeper application-level control and a more integrated data-centric security posture. While many aspects have been positive, we've encountered a persistent and significant challenge that I believe warrants a thorough community evaluation: unexpected and substantial traffic drops at the Netskope NewEdge PoPs.
Our architecture follows a fairly standard model. We deployed the Netskope client with a fail-open configuration for high availability, steering all web and cloud application traffic (including SaaS) through the nearest NewEdge PoP. Our tenant is configured for real-time inline inspection across all our defined policies. The migration itself was phased and, from a project management standpoint, went smoothly.
However, our network performance monitoring began flagging issues almost immediately post-cutover. We are seeing consistent TCP traffic drops at the PoP ingress that do not correlate with any of our configured security policy blocks. These drops manifest as:
* Increased TCP retransmission rates (2-3x baseline from our Zscaler era) for certain SaaS applications, particularly those with high-frequency, small-packet exchanges.
* Intermittent connection timeouts during large file uploads to cloud storage platforms, which previously were rock-solid.
* A measurable increase in "tcp_conn_fail" events in our client logs, especially from our branch offices in regions with slightly less dense NewEdge coverage.
We have engaged extensively with Netskope support, and their investigations typically point to their "intelligent steering" and the dynamic nature of their NewEdge network. The suggested remediations have included adjusting client steering configurations and tweaking certain TCP stack parameters via their client configuration profiles. While these have provided minor improvements, the core issue of higher-than-anticipated drop rates persists.
My purpose in sharing this is twofold. First, to see if other enterprises on a similar path have encountered comparable traffic fidelity issues and what, if any, operational or architectural adjustments proved effective. Second, to provide a framework for those evaluating such a migration. From a procurement and vendor evaluation standpoint, this underscores the criticality of expanding your proof-of-concept (PoC) criteria beyond features and compliance checks. I would now strongly advocate for any PoC to include:
* **Baseline Performance Benchmarking:** Measure key TCP metrics (retransmissions, latency variance, connection establishment time) from your major sites using your incumbent service *before* the trial.
* **PoC Traffic Profiling:** Ensure your trial traffic mirrors your real production mix—don't just test with generic web browsing. Include your specific mission-critical SaaS apps, large data transfers, and real-time protocols.
* **Vendor PoP Transparency:** Require detailed maps and performance data for the vendor's PoP locations relative to your offices and cloud providers. Understand their upstream providers and any potential peering bottlenecks.
* **Contractual Service Levels:** Negotiate service level agreements (SLAs) that go beyond simple uptime. Push for metrics based on packet loss, latency, and jitter from your user endpoints to the service PoP.
We are not considering a rollback, as the data security features are delivering tangible value, but the network performance gap is a notable operational tax. I'm keen to hear if this is a common teething pain with Netskope's architecture, or if our experience points to a need for a more fundamental design review on our part. Any insights from the community on tuning for optimal traffic flow, or lessons from your own vendor-to-vendor migrations, would be immensely valuable.
null
I'm an integration architect at a 5000-employee manufacturing firm, managing all external API and data flows, and we've had Zscaler ZIA in production for four years, with a secondary Netskope tenant for shadow IT discovery and specific CASB controls for about two.
- **Application-layer control precision**: Netskope's session-based inspection allows for granular, stateful actions like "allow upload but block download" within a single SaaS app session, which ZIA's proxy struggles with. We achieved this with about 30% fewer policy rules.
- **True operational cost**: Zscaler's announced per-user price is often $5-7, but our final cost with required support and premium SKUs was $9.50/user/month. Netskope's SWG+CASB list was $11, but we negotiated to $8.75 with a three-year commit, though their professional services for custom SSL decryption policies added a one-time $25k fee.
- **Throughput and latency reality**: In our performance testing, ZIA PoPs consistently delivered 950-1000 Mbps per tunnel for our major sites, with failover under 3 seconds. Netskope NewEdge PoPs, using the same physical test clients, showed higher variance, dropping to 400-600 Mbps during sustained 10-minute loads, which aligns with your traffic drop observation.
- **Support and escalation model**: Zscaler's TAC, in our experience, routes based on component (ZIA, ZPA, ZDX) and can cause delays for cross-issue tickets, with initial response averaging 45 minutes. Netskope support is unified but tiered; standard support had 90-minute responses, and we had to purchase a premium plan to get our architectural questions answered within 30, adding 15% to the annual cost.
Given your focus on application-level control, Netskope is the stronger technical choice, but only if your network links have 30-40% overhead to absorb the performance variance we've both seen. To make a clean call, tell us your average concurrent Mbps per PoP and whether your primary use case is threat prevention or precise data loss control.
Single source of truth is a myth.
Oh man, that line about performance monitoring flagging issues immediately hits home. We went through a similar phased migration about a year ago, and our Grafana dashboards lit up with the same pattern.
We never got to a "substantial" drop level that impacted users, but we saw consistent, weird 2-3% packet loss on specific paths to certain cloud regions, especially AWS us-west-2, that simply didn't exist with our old setup. It wasn't the client or the PoP itself, but the handoff from the NewEdge network to the public internet. It felt like a routing/peering hiccup that would come and go. Netskope support's stance was basically "your traffic is reaching its destination, minor loss is normal," which was... frustrating.
Have you been able to correlate the drops to specific destination ASNs or regions? For us, running continuous MTR traces during the drops was the only way to get them to actually look upstream.
Spreadsheets > opinions