Most teams don't leave Zscaler because it stopped working. They leave because the license true-up doesn't match what they actually use, because the policy sprawl is now owned by two people who both want to quit, or because a support ticket for a broken PAC file took eleven days to close. If any of that sounds familiar, this piece is the walkthrough: how to figure out what you actually need, who belongs on the shortlist, and what the migration really looks like once the contract clock starts ticking.

Why teams revisit Zscaler

The reasons are boringly consistent across the teams I've talked to. In rough order:

Licensing structure at your actual size. Zscaler's editions (Business, Transformation, Unlimited) bundle ZIA, ZPA, ZDX, deception, browser isolation, and other modules in ways that make sense for a Fortune 500 but often don't for a 400-person company. You end up paying for a suite when you actively use two modules.

Policy and deployment complexity. ZIA policy trees, ZPA app segments, PAC files, forwarding profiles, SSL inspection exceptions, and identity mapping across all of it — this is real work, and it tends to consolidate into a small number of engineers who become single points of failure.

Proxy latency, sometimes. The service edge is genuinely global and generally fast, but SSL inspection plus DLP plus browser isolation stacked on the same flow can push tail latency into user-visible territory. Real User Monitoring dashboards catch it, users complain about it, and the fix is often "turn off the thing you're paying for."

Support experience at mid-market pricing. Enterprise customers get named CSMs and reasonable response times. Mid-market accounts often report slow tickets, RCA delays, and pressure to upgrade tiers for parity.

Suite-vs-use mismatch. If you bought Transformation Edition for ZPA and haven't turned on deception, isolation, or ZDX in eighteen months, you're subsidizing modules you don't operate.

None of these are indictments of the product. They're signs that the fit has drifted, which is a normal thing for a five-year-old contract to do.

Requirements triage: what you use vs. what you bought

Before you look at a single alternative, separate what you actively depend on from what came in the box. Pull the last 90 days of admin activity, policy hit counts, and per-module usage telemetry. You're looking for three buckets:

1. Load-bearing. Policies with real traffic, apps with real users, integrations that would break something if they disappeared tomorrow.

2. Nice to have. Features you configured, use occasionally, and could replace with a point solution or live without.

3. Dead weight. Modules you're licensed for and don't operate. Deception is a common one. ZDX in shops without a formal digital experience program is another.

A useful exercise: write down the top ten access flows you actually care about (SSH to prod, RDP to Windows jump hosts, internal web app, database access for BI team, Kubernetes API, and so on). If your incumbent isn't doing meaningful work on those flows, everything else is decoration.

The output of this triage is a requirements list that reflects your actual security posture, not your contract line items. That list is what you evaluate alternatives against.

The alternatives landscape

The market splits cleanly into three profiles. Which one fits depends less on features and more on how much infrastructure your team wants to operate and how broad the scope needs to be.

A few honest observations about each:

Full SASE suites get you closest to a like-for-like replacement, but you're often trading one large, complex platform for another. If your problem with Zscaler is architectural (proxy latency, policy sprawl) or commercial (licensing at your size), moving to Netskope or Prisma won't fix it. You'll just have a different vendor doing the same thing.

ZTNA-first platforms are the right answer when your dead-weight audit reveals you're mostly using ZPA. If private application access is the load-bearing capability and you use ZIA lightly, a focused ZTNA product plus a lightweight web filter (or your endpoint's built-in) is usually simpler, cheaper, and faster to operate. This is where Twingate lives.

Cloud-native options are compelling if 90% of your resources sit in one cloud and your identity is already there. They're less compelling if you have significant on-prem infrastructure, homelab-style edge cases, or a strong preference for a vendor whose entire business is remote access.

Building a defensible shortlist

The shortlist should reflect the size and shape of your team, not the size and shape of the market.

Lean IT team (5–20 IT/security headcount, mid-market):

• Cap the shortlist at three vendors. More than that and evaluation eats a quarter.

• Weight heavily toward operational simplicity: deployment time, agent behavior, policy model, and self-service admin.

• Prefer transparent per-user pricing over "contact sales" tiers. Your budget cycles are shorter and your finance team wants a number.

• Require a working proof-of-concept in under a week with your own resources, not a canned demo environment.

Large security organization (50+ security headcount, enterprise):

• Shortlist can go to five. You have the people to evaluate in parallel.

• Weight toward integration surface: SIEM, SOAR, IdP depth, device posture, HR system provisioning, ticketing.

• Require reference customers in your industry and size.

• Model TCO across a three-year window including migration cost, not just year-one license.

For both, the shortlist criteria should include architectural questions, not just feature questions:

• Does the vendor route traffic through their infrastructure, and if so, is that acceptable for your data flows?

• What's the failure mode if the control plane is unreachable? Do existing sessions stay up?

• Is there an on-prem or self-hosted option if regulatory posture requires it?

• What's the connector or gateway model, and does it require inbound firewall rules? (If yes, that's a step backward from where you probably want to be.)

Evaluation criteria and a proof-of-concept plan

A scorecard beats a gut check. Score each vendor 1–5 on each criterion and weight based on what your triage exercise surfaced.

For the POC itself, keep it tight:

1. Two weeks, three resources, ten users. One SSH target, one internal web app, one database. Real users from three teams, not admins on test accounts.

2. Write the migration runbook during the POC. If you can't document how you'd move all users in the vendor's model, that's a data point.

3. Break things on purpose. Kill the connector, disconnect the control plane, revoke a user mid-session. Watch what happens.

4. Include a security review. Read the vendor's SOC 2, their pen test summary, and their incident disclosure history. If any of those are unavailable, that's also a data point.

Migration mechanics

Migration off Zscaler is where most projects stall. Not because it's technically hard, but because coexistence during the cutover is where subtle breakage lives.

Policy translation. Export your ZPA app segments and ZIA URL policies. Map each to the equivalent construct in the new platform. Zscaler's policy model is deep — some rules won't translate directly, and that's fine. This is a chance to prune the dead rules you never got around to cleaning up.

Agent coexistence. Running two ZTNA agents on the same endpoint is almost always fine for short periods, but it depends on the TUN/TAP interface behavior and split-tunneling logic of both. Test on a few machines before rolling to a pilot group. If the new agent uses split DNS or claims specific IP ranges, verify there's no conflict with Zscaler's Z-App.

Connector rollout. Deploy connectors in every network segment where you have private resources, ideally two per segment for HA. In Twingate's case, connectors are outbound-only and can run as Docker containers, systemd services, or Kubernetes deployments — you don't need to open inbound firewall rules, which is the main thing to verify against your incumbent's model.

User communication. The single biggest cause of migration friction is silent client swaps. Announce it, publish a rollback procedure, and give users a way to reach IT that doesn't depend on the thing you're changing. A three-phase rollout (pilot → early adopters → general) with clear success criteria for each phase is standard.

Contract timing. Start the evaluation 6–9 months before your Zscaler renewal. Aim to have the new platform in production for 60–90 days before the renewal date. This gives you real leverage in the renewal conversation, whether you're actually leaving or using the alternative to negotiate. Do not start the POC three weeks before renewal — you'll either sign a bad renewal or run a bad migration.

For the tactical VPN and legacy-remote-access cutover pieces, our VPN to ZTNA migration guide covers the endpoint and network-layer mechanics in more detail.

Migration checklist

• Requirements triage complete (load-bearing / nice-to-have / dead weight)

• Shortlist finalized with weighted scorecard

• POC completed with real users on three real resources

• Security review of shortlisted vendors (SOC 2, pen test, incident history)

• Policy export from Zscaler, mapped to new platform's model

• Connector deployment plan per network segment, with HA

• Agent coexistence tested on macOS, Windows, and any Linux endpoints

• Pilot group defined (10–25 users across at least three teams)

• Rollback procedure documented and tested

• Communication plan drafted with IT escape hatch

• Renewal date confirmed with procurement; new platform live 60+ days prior

• SIEM integration verified with real event flow

• Zscaler decommission plan with data retention timeline

Red flags — including in your own requirements

Red flags in vendors:

• Pricing that requires a sales call for anything above the free tier. Fine for enterprise, painful for mid-market planning.

• No published architecture diagram. If you can't tell where traffic flows and where policy is enforced, you can't do a real security review.

• Support tiers where basic response time requires an upgrade. You'll find out about this after you sign.

• Feature demos that only work in the vendor's sandbox. Insist on POCs against your own infrastructure.

• Reluctance to discuss failure modes. Every distributed system fails; vendors who don't want to talk about how are hiding something.

Red flags in your own requirements:

• Requirements copy-pasted from your current Zscaler config. You're describing what you have, not what you need.

• Feature lists longer than fifty items. You will not evaluate fifty features rigorously. Cut to twenty.

• No one on the evaluation team who represents end users. Every ZTNA product looks great to admins; users are the ones who will file tickets.

• A hard requirement for "SASE" as a category rather than the specific capabilities you actually use. Category-based buying is how you ended up over-licensed the first time.

• Timelines that assume the vendor's marketing rollout speeds ("deploy in an afternoon") apply to your real environment.

The best migration decisions I've seen came from teams who spent more time on their requirements than on vendor demos. The worst came from teams who let a renewal date force a decision. If the calendar is squeezing you, negotiate a short extension rather than sign a five-year commitment to whichever vendor happened to demo well in the last thirty days.

Closing

For more on how Twingate's architecture compares to proxy-based platforms and how to plan a migration off legacy remote access, see the Twingate documentation and the deployment guides for Connectors and Clients.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.