How to Replace Zscaler in 30 Days: A Migration Playbook for IT Teams

Zscaler migrations have a reputation. The Zscaler partner SOW arrives with a discovery phase, a design phase, a tunnel migration phase, a ZCC rollout phase, a ZPA App Connector decom phase, and a hyper-care window. Three to six months. Some of that work is real, because Zscaler is genuinely deep in the network. Some of it is theater.

This playbook is for IT teams who want to get the real work done in 30 days and stop paying for the theater. It assumes you're replacing Zscaler with an agent-based Zscaler alternative (dope.security is the example, but the cadence applies to any agent-based SWG). A mid-market healthcare organization used this pattern to swap Zscaler for dope.security and reshape its renewal in the same cycle. (Healthcare Zscaler displacement case study.)

Before you start: 30 days assumes these preconditions

A 30-day Zscaler migration is realistic when:

• You have an MDM in place (Intune for Windows, Jamf or Intune for macOS).

• SSO is wired up through Microsoft Entra ID or Google Workspace.

• A single IT owner is named for the migration.

• Your ZTNA strategy for internal apps is decided. Either you're keeping ZPA, you have a separate ZTNA point product, or you've confirmed the apps don't need ZTNA in the first place. (For the ZIA vs. ZPA split decision, see Zscaler ZIA vs ZPA.)

Without those, add a week per missing precondition. Most teams have the first three. The ZTNA question is the one that surprises people.

If you want to compare replacement options before committing, see Zscaler Alternatives in 2026.

Phase 1: Inventory (days 1–5)

Zscaler in production usually means six things at once. Document each one before you touch anything.

ZIA inventory. SKU tier (Business, Transformation, ZIA Edition), bandwidth tier, the URL filtering and SSL inspection policies in production, custom URL categories, file type controls, IPS/DPI policy, sandbox configuration, and any custom block/warn pages.

ZPA inventory. Application segments, segment groups, connector groups, App Connectors deployed in each private network, browser access apps, and the user-and-machine policy.

ZCC inventory. Versions deployed across the fleet, ZCC profile configurations (forwarding profile, app profile, trusted networks), tunnel mode (Z-Tunnel 1.0 vs 2.0), and any device posture rules.

Tunnel inventory. GRE and IPsec tunnels from each office or data center to Zscaler PoPs. PAC file deployment scope (proxy.pac, wpad.dat). Any explicit-proxy configurations.

Integration inventory. SIEM forwarding (Splunk, Sentinel, Chronicle), IdP (Entra, Okta, Google), MDM (Intune, Jamf), and any APIs feeding ZIA or ZPA from the rest of the stack.

The "things Zscaler doesn't actually do well" list. Highest-value part of the inventory. AI prompt content. Personal ChatGPT and Claude logins on corporate-tenant domains. MCP server traffic from agentic AI tools. (See MCP Servers Are the New Shadow IT.) Geographic edge cases where the closest Zscaler PoP adds real latency. The new SWG should pay for these gaps.

Deliverable at end of phase 1: a one-page state-of-the-stack brief and a clear list of what stays on Zscaler, what moves to the new SWG, and what gets retired entirely.

Phase 2: Pilot (days 6–12)

Tight, instrumented, real traffic.

Pilot scope. 25 to 50 endpoints across IT, security, and one business unit. Mac and Windows mix. Remote and in-office mix. One pilot group in MDM.

Pilot mechanics.

1. Stand up the dope.console. Sign in with Google or Microsoft on the instant trial. You're in the console in minutes.

2. Translate the ZIA URL filtering policy into dope.console. Category mappings are mostly one-to-one. Custom allow/block lists port directly.

3. Enable on-device SSL inspection. This is the architectural change. ZIA does inspection in the cloud proxy. dope.security does it on the endpoint. For the architecture explanation, see On-Device TLS Inspection.

4. Push the agent via MDM. For Intune and Jamf, follow the MDM deployment playbook. Both flows are scripted and signed.

5. Coexistence mode. During pilot, leave ZCC installed on pilot endpoints with its forwarding profile set to bypass dope-managed domains, or scope ZCC down to the apps you're keeping on Zscaler (typically the ZPA scope). The goal is to compare side-by-side without two SWGs fighting for the same traffic.

6. Run in monitor mode for 72 hours. Watch the URL filtering hit logs. Catch the apps that no one mentioned in inventory.

7. Flip to enforce on the pilot group at end of day 12.

Don't expand the pilot until the logs are quiet for two business days. Most teams find the surprises in the first 48 hours.

Phase 3: Rollout (days 13–24)

This is the long phase, because Zscaler is in a lot of places. Don't rush. Don't drag.

Rollout pattern.

• Days 13–14. Push to the rest of IT and engineering.

• Days 15–18. Push to the largest user populations in waves of equal size. Use existing org units in your MDM.

• Days 19–22. Catch the long tail. Contractors. Kiosks. BYOD-with-MDM. The salesperson who's been on PTO.

• Days 23–24. Office and site rollouts. The endpoints behind the GRE/IPsec tunnels are the last to switch in most plans.

What "ready for rollout" looks like.

• The agent auto-deploys via MDM with no manual intervention.

• SSO works on the first try for every new user.

• Block and warn pages are branded with your IT helpdesk contact.

• Your support team has a one-page runbook for "the internet is broken." (Spoiler: it's bypass list, every time.)

• ZIA and dope.security are running side-by-side on the rollout cohort with ZCC narrowed to ZPA-only forwarding.

Phase 4: Cutover and decom (days 25–30)

Where the savings start showing up.

The cutover (days 25–27).

1. Repoint office traffic. The GRE and IPsec tunnels to Zscaler PoPs come down. Internet traffic from each site goes direct to the internet again. dope.security inspects on the endpoint, so the tunnels are no longer the inspection path.

2. Retire PAC files. proxy.pac and wpad.dat get pulled from group policy, MDM configuration profiles, and DNS. If users rely on explicit proxy settings in any app, fix those at the same time.

3. Disable ZIA forwarding in ZCC. If you're keeping ZPA, narrow the ZCC forwarding profile to ZPA-only. If you're not keeping ZPA, ZCC comes off entirely.

4. Pause ZIA at Zscaler. Confirm the ZIA dashboard shows traffic dropping to zero. Hold the contract; don't auto-renew mid-cutover.

The decom (days 28–30).

• ZPA App Connectors. If you're retiring ZPA, decommission the App Connector VMs in each private network. Free the IPs. Remove the firewall rules that allowed connector outbound to Zscaler's broker cloud.

• ZCC removal from MDM. Pull ZCC from the Intune and Jamf packages so it doesn't reinstall on a wipe.

• DNS cleanup. Remove any Zscaler-specific DNS forwarding, CNAMEs, and any internal records pointing at App Connectors.

• SIEM cleanup. Decommission the ZIA NSS feed and the ZPA log streamer once historic logs are archived.

• Cert authority. If you trusted Zscaler's intermediate CA on endpoints for SSL inspection, remove it from MDM trust profiles. Trust the new SWG's CA instead.

• Network policy. Re-evaluate the egress firewall rules at each office. Without GRE/IPsec to Zscaler, the egress posture changes.

• Renewal letter. Confirm the cancellation notice window with your Zscaler rep. Most contracts require 60 to 90 days written notice, so this conversation should have started in phase 1.

Common gotchas

A few patterns we see often enough to call out:

• Certificate pinning. Some apps pin a specific cert chain and refuse SSL inspection from any SWG. Bypass them. Same answer Zscaler would give.

• Conferencing latency complaints. If users complain that Zoom or Teams "feels different" after cutover, it's usually that they were used to a Zscaler-PoP routing pattern. Confirm with a traceroute. Almost always, direct-to-internet is faster.

• Forward-proxy chained authentication. Some legacy applications were configured to authenticate through Zscaler. Catch them in pilot, not at cutover.

• The "we still need ZPA" reflex. Sometimes true. Often, the internal apps in question are already SaaS or have moved to a different identity-aware proxy. Check the actual usage logs before assuming you need to keep ZPA.

• The "bundled with our Crowdstrike deal" objection. Run the actual math. Zscaler bundle discounts often look generous on the line item and modest on the total cost of ownership over three years. Most agent-based replacements come out ahead inside 12 months.

What "done" looks like

At the end of day 30:

• Every managed endpoint is running the new SWG agent.

• Every URL request, including HTTPS, is being inspected on-device. No more cloud-proxy hop.

• Policy changes push from the cloud console to every endpoint in seconds, not the 30 to 60 minutes some ZIA policy distribution cycles took.

• Cloud Application Control is restricting personal Microsoft, Google, ChatGPT, and Claude logins on sanctioned domains. (See Blocking Personal Claude Accounts.)

• Dopamine DLP is inspecting file uploads and AI prompts on-device. (See Meet Dopamine DLP.)

• GRE and IPsec tunnels to Zscaler are torn down.

• ZCC is off the endpoints (or scoped down to ZPA only if you're keeping it).

• ZPA App Connectors are either decommissioned or owned by a different ZTNA product.

• The Zscaler renewal letter is filed under "no longer applicable."

Ready to scope yours?

If you're planning a Zscaler replacement, the instant dope.security trial is the fastest way to see on-device SSL inspection running against your own traffic. Or book a 20-minute working session and we'll walk the ZIA and ZPA inventory for your environment in real time.