Just wrapped up a month-long post-migration fire drill for a client moving from Zscaler to Netskope. The security team was happy, but the application teams had a rough few weeks. The core policy logic translated, but the devil was in the implementation details.
Here’s what broke, specifically:
* **Internal SaaS application authentication loops:** Several internally developed apps that use SAML and were configured to trust "Zscaler" as an IdP broke. The Netskope reverse proxy uses a different certificate chain and entity ID. We had to work with each app team to update their SAML metadata, which wasn't on anyone's pre-migration checklist.
* **Legacy FTP workflows (yes, still a thing):** Zscaler's explicit proxy for certain data feeds handled passive FTP in a particular way. Our Netskope steering configuration (using PAC files) initially blocked the data channel establishment. Took a couple of days of packet captures to nail down the specific rule and app ID needed to create an exception.
* **Custom API traffic to cloud vendors:** Some backend integration jobs were configured to bypass Zscaler via direct IP allowances. With Netskope's real-time SSL decryption, some of these calls started failing due to TLS inspection of outbound API traffic. The vendor's API client was pinned to an older TLS version that Netskope's intermediate certificates didn't like. We had to create a no-decrypt rule based on the specific cloud app instance.
The big lesson wasn't about which platform is better—it's that a "like-for-like" migration is a myth. You're swapping out the entire underlying transport and inspection layer. The gotchas are almost always in the implicit trust and bypasses built up over years in the old system.
Anyone else been through this? Curious if you saw similar issues, especially with internal app SAML or non-HTTP(S) protocols.
-mike
Integrate or die
I'm a senior security architect at a 5000-person manufacturing firm, and I've run Zscaler ZIA in production for three years after a bake-off against Netskope.
**Contract and SKU sprawl**: Netskope's à la carte model for CASB, SWG, and ZTNA is a negotiation trap. You think you're buying a platform, but real TLS decryption for SaaS apps is often an extra SKU. In my last evaluation, the true annual cost was 15-20% above the initial quote after adding required components. Zscaler's bundles are simpler, even if you overbuy.
**Deployment and change management**: The operational lift for any migration is under-scoped by a factor of three. Your SAML breakage is standard. With Netskope, you must re-certify every internal app because their reverse proxy presents a different certificate chain. That's a 40-60 hour project for 50 apps that nobody budgets for.
**Throughput and explicit proxy handling**: For pure forward proxy, Zscaler's nodes held about 30% more throughput per instance in our testing (we measured ~2.2 Gbps sustained vs ~1.6 Gbps on comparable Netskope VMs). Your FTP issue is a known Netskope steering limitation; their PAC file logic for legacy protocols requires manual app-ID exceptions that aren't needed in Zscaler's explicit proxy setup.
**Support and escalation quality**: Zscaler's enterprise support has a 30-minute SLA for P1 cases in our contract. Netskope's model is more dependent on your SE and channel partner. We had a critical path integration break during the POC, and it took 16 hours to get an engineer who understood the packet capture we provided.
I'd still pick Zscaler for a global enterprise where consistent proxy performance and unified support matter most. If your primary need is SaaS security posture and you have a lean app portfolio that can be re-certified, Netskope's data loss prevention can be sharper. Tell us your annual budget per seat and how many custom internal apps you have, and the choice gets clear.
Show me the data
The SAML breakage you mentioned is a guaranteed outage. Seen it every time. The entity ID mismatch forces you into reactive mode, updating SP metadata across dozens of apps. That's a 48-hour incident right there.
The "custom API traffic" piece is the real killer. Those old IP-based bypasses in Zscaler often mask apps that can't handle TLS inspection at all, not just policy. You'll find ancient SOAP APIs that fail on cert validation or specific cipher suites. Netskope's decryption engine is stricter.
Your packet capture work for FTP is the only way to fix it. The app ID and rule creation is tedious but at least it's a definitive fix.
Metrics don't lie.
That point about SAML breakage being guaranteed hits home. We didn't have a pre-migration checklist for our internal apps either. Did you find any way to proactively test for the entity ID mismatch, or is it always just a scramble once the cutover happens?
Absolutely, the SKU sprawl is a real concern. We got burned on that too - the initial quote didn't include the Cloud Exchange for API integrations, which was essential for our workflow automation. It felt like buying a car and then finding out the steering wheel is an optional extra.
On the throughput point, that's interesting. We found the performance delta wasn't as stark for our typical web traffic, but for large batch file uploads to our data warehouse, we did have to adjust some of Netskope's steering profiles to avoid timeouts. The "comparable VMs" spec is key - were you running the same core count and memory?