How do I do a phased rollout of ZPA without breaking existing VPN users?

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!

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.

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.

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.

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.

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.

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.

You've gotten some great technical advice here already, especially about the parallel access model. I'd zero in on your phrase "I'm nervous about switching them over," because that's the core of a successful pilot. It's not just a technical test, it's a change management stress test.

Start your configuration by defining application segments for your absolute minimum viable services - think your core authentication system, a critical internal web portal, and maybe a file server. This is your "day one survival" list. Then, for your pilot group, select individuals, not just a department, who are both technically savvy and good communicators. You need people who will provide detailed, calm feedback when their Outlook can't find the Exchange server, not just file a generic "broken" ticket.

The biggest gotcha isn't technical, it's expectation setting. You must be crystal clear with the pilot group that they are testing a *new* access method, and they should report *everything* that feels different, even if it still works. A slight latency increase on an intranet page or a weird certificate prompt is your gold. If you frame it as a seamless cutover, you'll miss the subtle bugs that will snowball during a full rollout. Budget twice the support time you think you'll need for that pilot phase.

I completely understand your nervousness, as we felt the same way during our initial planning. That beginner-friendly approach you're looking for starts with defining a very specific pilot group success criteria before you touch any application segments.

Beyond just picking a department, you need to pick a specific workflow within that department to test. For example, we defined success as "the pilot group can complete their daily inventory reconciliation process using only ZPA," which included three specific applications and two internal URLs. This gave us a clear, measurable goal smaller than "switch a department." The gotcha we didn't anticipate was user training fatigue; even a willing pilot group needs simple, repeated instructions on when to use which connection method, or they'll default to the familiar VPN at the first hiccup.

How are you planning to define "success" for your test group? Is it just access, or completion of a specific business task?

That training fatigue is real. We called ours "ZPA refugees" - they'd flee back to the VPN at the slightest problem. Our fix was making the success criteria binary for the pilot phase: if you're in the pilot, the VPN profile is removed from your device entirely. No fallback.

It forced us to fix issues immediately and proved the path actually worked under real pressure. The metric shifted from "can they access the app" to "are they blocked from their work." That's the stress test you need.

>Pilot with IT or a friendly department first.

That's a classic starting point, but it's a flawed benchmark. IT's traffic patterns and app dependencies are nothing like finance or engineering. Their "success" creates false confidence.

Also, running two network stacks side-by-side isn't just overhead, it's a cost multiplier. You're paying for double the client licensing, double the monitoring tools, and your help desk time per ticket goes up 40% because they're troubleshooting two potential failure points.

We skipped the "friendly" pilot and went straight to a revenue-critical team with hard SLAs. Broke more things, but proved real viability.

Your beginner-friendly approach is exactly right, and that nervousness is a good sign you're thinking about it carefully. A lot of the advice here jumps straight to complex pilot strategies, but your core question about what to configure first is key.

I'd start even before the application segments. The first technical step in our phased rollout was setting up the DNS conditional forwarder to point only our pilot group's devices to the ZPA DNS resolvers. This creates a clean split at the name resolution level, so your pilot users automatically discover the ZPA paths for the apps you define, while everyone else keeps using the VPN's DNS. It's a single, controlled change that isolates the test without touching anyone's client config.

The gotcha we didn't see coming was with cached credentials in browsers and thick clients. Even with the DNS split working, some applications on our pilot machines were still trying to reach old, hard-coded VPN gateway IPs they had saved. We spent a week just clearing caches and credential managers. So maybe add that to your pilot checklist: flush everything that isn't system DNS.

That beginner-friendly approach is exactly right, and that nervousness is a good sign you're thinking about it carefully. A lot of the advice here jumps straight to complex pilot strategies, but your core question about what to configure first is key.

I'd start even before the application segments. The first technical step in our phased rollout was setting up the DNS conditional forwarder to point only our pilot group's devices to the ZPA DNS resolvers. This creates a clean split at the name resolution level, so your pilot users automatically discover the ZPA paths for the apps you define, while everyone else keeps using the VPN's DNS. It's a single, controlled change that isolates the test without touching anyone's client config.

The gotcha we didn't see coming was with cached credentials. Some of our web apps held onto login sessions tied to the old VPN source IP. When the pilot group started hitting them from the ZPA source IPs, it triggered fresh logins and even a few account lockouts. A heads-up to your help desk about potential re-authentication prompts for the pilot group can save a lot of panic.