Migrated from Zscaler to Netskope - what broke in the first month

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.

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.

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?

The SAML breakage and internal app updates sound like a major project cost that wouldn't show up in the initial vendor quote. How did you handle the resource allocation and internal billing for that work with the client? Was it covered in the migration SOW, or was it an unexpected overrun?

Great point about the internal SAML apps. That entity ID and certificate chain mismatch is such a classic gotcha. It turns what should be a transparent proxy swap into a major configuration overhaul for every app team.

On the FTP and custom API issues, your packet capture approach is exactly right. We found Netskope's decryption is less forgiving of non-RFC-compliant traffic than Zscaler's proxy. For those old integrations, sometimes the only path was to create a very specific, temporary bypass rule in Netskope using the app ID, and then work with the vendor to modernize their API's TLS implementation. Did you run into any pushback from the security team on creating those exceptions, or were they understanding given the legacy nature of the workflows?

Great question. It was definitely an unexpected overrun in our case. The migration SOW covered the infrastructure swap and core policy migration, but it assumed "like-for-like" functionality for user-facing apps. That SAML mismatch turned into a hidden project tax.

We had to go back to the client with a change request for the app reconfiguration work. It ended up being billed as a separate professional services engagement, pulling in our IAM specialists and their app teams. Honestly, it strained the relationship for a bit - the security team's budget was separate from the application teams', so there was internal finger-pointing about who should pay for the fix.

The lesson for next time? Any migration SOW now has a mandatory discovery phase where we inventory all internal apps using the proxy as an IdP and build the config updates into the initial timeline and cost. You can't just trust the pre-migration checklist from the security side.

Oh, the "optional steering wheel" analogy is perfect. We hit the exact same thing with their API security module. It's sold separately and if you have any public facing APIs, you basically need it. That wasn't clear until we were deep in the design phase.

Your note on throughput and VMs is spot on. We saw similar results with standard traffic, but the initial benchmarks were misleading. They were using general instance types. When we matched our ZIA proxy specs core for core and memory for memory in our own cloud, the cost comparison shifted significantly. The per VM cost was higher, and we needed more of them to hit our same throughput targets for those bulk data transfers.

You've hit on a critical, often invisible, cost center: the internal chargeback scramble. That post-migration finger-pointing between security and app teams' budgets can derail a project faster than any technical hiccup.

Your solution of baking the IdP/app discovery into the SOW is the only way to prevent it. We've started using a simple RACI addendum for migration projects. It forces all stakeholders - security, IAM, and each major app team - to sign off on the pre-cutover inventory and explicitly own their slice of the re-certification work. It turns a hidden tax into a planned, and funded, phase of work.

Without that, the security team inevitably eats the cost to save the relationship, which just sets a bad precedent for the next upgrade.

Yep, that's the classic migration pain. The SAML and FTP issues are almost a rite of passage.

What caught us off guard was the custom API traffic. Those IP bypasses often hide more than just policy exceptions. We found a few ancient SOAP services that were hard-coded to ignore cert warnings, and Netskope's TLS inspection just killed them. It became a mini-project to track down each one.

Did you run into any issues with Netskope's user agent string being different from Zscaler's? Some of our older internal logging and analytics dashboards that filtered by "Zscaler" in the user agent started dropping traffic silently. That one took a while to trace.

> It was definitely an unexpected overrun in our case.

Exactly. That's the universal experience. The vendor's scope of work is always about the proxy infrastructure and the core policy migration, with this implicit, dangerous assumption of functional parity for all connected systems. The moment you cut over, you're no longer just managing a proxy; you're responsible for breaking every integration that depended on the previous proxy's specific fingerprint, from SAML to user agent strings.

We've learned to structure the SOW with explicit, billable phases now. Discovery is one, but crucially, "integration validation" is another. That phase involves packet captures and test transactions for *every* non-standard flow *before* the cutover. It adds 20% to the project timeline upfront, but it turns those hidden costs into a visible, agreed-upon line item. The alternative is exactly what you described: strained relationships and security footing the bill for app team technical debt.