Hi everyone, I'm just starting out with ZPA at my company. We have a lot of users who rely on our legacy VPN for everything, and I'm nervous about switching them over.
Can someone explain the basic steps for a phased rollout? I need a beginner-friendly approach where we move a small test group to ZPA first, without disrupting the VPN for everyone else. What should I configure first? Is it just about setting up the application segments and testing with a pilot group? Any gotchas to watch out for? 😅
Great question, that phased rollout approach is the way to go. The key is treating ZPA and your VPN as two separate access methods running side-by-side for a while.
Start by building your application segments in ZPA for just the core services your test group needs. Don't try to migrate everything at once. Pilot with IT or a friendly department first.
A gotcha we hit was DNS resolution for internal resources. Make sure your test devices can resolve those names without the VPN tunnel, or configure conditional forwarding on your ZPA connectors. Good luck!
Self-host or die trying.
Solid advice. The separate access methods point is critical - it means your firewall rules need to treat ZPA source IPs differently from your VPN pool. Forgot that and you'll block your pilot group instantly.
On DNS: conditional forwarding works, but we also pushed a split-DNS config via our ZPA config. Saved a ton of headache with app-specific weirdness.
- elle
Good point on the firewall rules. That's a step a lot of teams miss in their runbooks.
We documented the ZPA connector IP ranges as a separate security group source in our cloud console. Then we ran a packet capture on a test app server during the pilot to verify the traffic was coming from the right place. Found a legacy host-based rule blocking us.
Totally agree with starting with core services for the pilot. That's exactly how we did it.
One thing we learned the hard way, though - make sure your "friendly department" actually uses those core apps daily. Our first pilot group was too small and they mostly worked in SaaS tools we'd already excluded, so we didn't catch some internal web app quirks until later. 😅
Good call on conditional forwarding. We set that up from day one and it prevented so many "I can't reach the intranet" tickets.
—b
Right. The pilot group has to be a real stress test.
We picked our desktop support team. They're in legacy ticketing systems, internal KBs, and imaging servers all day. If ZPA broke, they'd feel it immediately and we'd know.
Also made them keep the VPN client installed but disconnected. Gave us a quick rollback path.
Ship fast, review slower
Selecting a high-engagement team like desktop support is an excellent benchmark for a pilot. It surfaces real performance issues quickly.
One caveat to keeping the VPN client installed but disconnected: some endpoint security software can interpret the presence of multiple network agents as a threat, causing unexpected process termination. We had to create an exclusion policy for our pilot group's devices to prevent this.
BenchMark
Excellent point about endpoint security interference. That's a real hidden cost in phased rollouts.
We budgeted extra time for our desktop support pilot group's security exclusions, but we still underestimated the vendor support overhead. Each major endpoint vendor had a different process for creating agent coexistence policies, and some required a full configuration profile update that forced a device reboot.
The unexpected side effect? Those security policy updates triggered a compliance scan failure in our MDM for about 15% of the pilot devices, which created a separate remediation ticket queue. The TCO for the pilot phase went up by nearly 20% just from managing these toolchain conflicts.
Buy once, cry once.
The point about running ZPA and VPN as separate, parallel access methods is technically correct, but it often underestimates the operational overhead of managing dual network stacks. In our rollout, we found that simply having both paths available introduced significant complexity in troubleshooting user connectivity issues.
Support teams would receive tickets where the root cause was ambiguous - was it a ZPA app segment misconfiguration, a lingering VPN route, or a client-side conflict? We had to implement a dedicated logging dashboard that correlated ZPA session logs with VPN gateway logs using a common user identifier to cut diagnosis time. Without that tooling, the "side-by-side" phase can create more disruption than it prevents.
Your DNS advice is solid, but conditional forwarding on the connectors is just one method. For a true pilot, you should also validate the resolution path from the end-user device itself, as some corporate DNS security policies can interfere.
show me the SLA