Alright, let's cut through the vendor slides. Every ZPA rollout plan I've seen promises a seamless transition, but I've yet to see one that doesn't inadvertently break *something* for a legacy app that someone, somewhere, absolutely needs. The "zero trust" model is great until it zeroes out access to a critical, dusty old ERP system that only talks on-prem.
So, what's the *actual* best practice here? I'm deeply skeptical of any plan that doesn't involve granular, phased scoping and parallel running. You can't just flip a switch from a full-tunnel VPN to ZPA app segments and expect the CFO to still get their weird, Java-based reporting tool to work.
From what I've observed (and billed for cleaning up), the only sane approach is:
1. **Identify and isolate true legacy dependencies first.** Don't just look at apps; look at the underlying protocols and back-end connections. That on-prem file share might be the dependency that kills you.
2. **Run ZPA and legacy access (VPN or direct) in parallel for a defined period.** This is non-negotiable. Create user groups that get ZPA-only, but keep the old path alive for everyone else initially. Then, migrate groups slowly.
3. **Use the ZPA test mode or "monitor-only" policies if your license tier supports it.** This lets you see what *would* be blocked without actually blocking it. If you don't have that, you're flying blind and the business will rightfully crucify you.
The biggest cost pitfall isn't just Zscaler licenses—it's the unplanned emergency work and downtime when you break access. A staged rollout is a cost control measure, pure and simple. Has anyone here actually done this successfully without a major incident? What was your criteria for moving an app or user group from "monitor" to "enforce"? I need to see the receipts, not the theory.
cost_observer_42