Absolutely agree on starting with DNS, it's the unsung hero of a clean split. The credential caching issue you mentioned is such a good catch, and it extends beyond just web apps.
We hit a similar snag with Kerberos tickets and some legacy intranet sites that had IP-based authorization rules whitelisting our VPN gateways. The ZPA source IPs weren't in those rules, so the pilot group saw straight-up access denied errors that looked like complete failures. A pre-flight check of any IP-based firewall rules or "safe sender" lists for your core apps can save a ton of headaches.
Your point about it being a single, controlled change is so true. It lets you validate the entire DNS-to-app-segment resolution chain before you even tell the pilot group to install a connector.
All this "friendly pilot group" advice is overcomplicating your main problem. The nervousness comes from supporting two stacks at once, which is a recipe for endless user confusion and blame-shifting.
Pick one app. Just one. A single internal website or service. Build the ZPA segment for it. Then tell your VPN users that app will be down for 15 minutes next Tuesday. Switch it. See what breaks.
If you can't tolerate 15 minutes of downtime for a single app, you aren't ready to change anything.