Having just wrapped up a 90-day, full-production migration from Zscaler Internet Access (ZIA) to Cloudflare One, I felt compelled to share our journey. It wasn't a simple "lift and shift," and the architectural differences required a significant rethinking of our policies and, crucially, our integration points. For anyone else considering this path, hopefully our lessons learned can smooth out some of the bumps.
Our primary drivers were cost consolidation (merging network and security stacks) and a desire for a more developer-friendly, API-first platform. While Zscaler served us well for years, the operational model felt increasingly siloed. Cloudflare's promise of a unified control plane for WARP (their client), network firewall, DNS filtering, and data loss prevention was compelling.
The migration itself was phased. We started with a pilot group, then moved to a co-existence model, and finally cut over entirely. The biggest conceptual shift was moving from Zscaler's explicit proxy model to Cloudflare's concepts of Gateway and Tunnel.
* **Replacing PAC Files & App Profiles:** We heavily relied on complex PAC files and Zscaler App Profiles for selective routing. In Cloudflare One, this translates to **Split Tunnels** and **Gateway Policies** based on domain, application, or destination IP. The granularity is there, but the logic lives in a different place.
* **API & Automation:** This was my personal battlefield. Cloudflare's API is extensive and well-documented, but automating the migration of thousands of firewall rules and URL filtering policies required building custom tooling. I ended up writing a translation layer that mapped Zscaler policy objects to Cloudflare's `account.firewall_access_rules.rules` and `gateway.lists`.
```python
# Simplified snippet of our Zscaler-to-Cloudflare rule translator
def translate_url_filter(zscaler_rule):
"""Convert a Zscaler URL Filter rule to a Cloudflare Gateway policy."""
cf_rule = {
"name": zscaler_rule['name'],
"precedence": zscaler_rule['order'],
"action": "block" if zscaler_rule['action'] == "BLOCK" else "allow",
"filters": ["http"],
"conditions": {
"operator": "or",
"conditions": [
{
"type": "url",
"value": {
"url": domain,
"path": path_pattern # Had to derive from Zscaler's pattern
}
} for domain in zscaler_rule['domains']
]
}
}
return cf_rule
```
**Key Lessons Learned:**
* **DNS Policy is Your First Line:** Cloudflare places a much heavier emphasis on DNS filtering as the initial, fast security layer. Get your DNS locations and policies solid before you even think about layering on HTTP/Network policies.
* **WARP Client Stability:** The WARP client is lightweight, but its logging is less verbose than Zscaler's. For troubleshooting, you'll live in the Gateway Network Logs dashboard. Ensure your help desk team is trained there.
* **The "Tunnel" is Fundamental:** `cloudflared` tunnels (our replacement for Zscaler Private Access) are brilliant but different. They're not a traditional VPN. Migrating internal applications required re-evaluating service authentication, as the tunnel presents a new source IP (Cloudflare's egress IPs).
* **Performance:** We saw a noticeable reduction in latency for most SaaS apps, which was a win. However, a few legacy on-prem apps, previously bypassed via PAC file, needed careful tuning in the Split Tunnel configuration to avoid hairpinning.
The transition is more than a vendor swap; it's a paradigm shift from a security-centric proxy to a performance-and-security-integrated global network. The automation capabilities and the synergy with other Cloudflare services (like Workers for edge logic) have already opened up workflows we couldn't easily build before.
api first
api first