Having completed a comprehensive migration from Zscaler Internet Access (ZIA) to Zscaler Private Access (ZPA) approximately three months ago, I am documenting the operational friction points and unexpected behavioral changes encountered. My team's evaluation was methodical, involving a phased rollout to distinct user cohorts, but several material disruptions occurred that were not apparent during the proof-of-concept stage. This report focuses on the specific workflows that broke, necessitating either architectural adjustments or procedural retraining.
The core disruption stemmed from the fundamental shift in security model: from a network-centric, proxy-based architecture (ZIA) to an identity-centric, application-segmented one (ZPA). This manifested in three primary areas:
* **Legacy Application Connectivity:** Internal applications that were previously accessed via IP address or non-FQDN internal hostnames, and which relied on NTLM or other non-standard authentication passthrough, failed outright. ZPA's requirement for a defined application segment with a valid FQDN (even if privately resolved) forced a significant inventory and remediation project. We had to:
* Standardize DNS entries for dozens of legacy systems.
* Reconfigure several Java-based admin consoles that could not accommodate the ZPA connector's method of traffic routing.
* Implement a small, temporary ZIA "island" for a handful of truly immutable systems, which added management overhead.
* **Scripted and Automated Processes:** Batch jobs, data warehouse ETL pulls, and infrastructure monitoring scripts that were whitelisted by source IP under ZIA broke silently. ZPA's principle of "no trust by network location" meant these machine-to-machine connections required service accounts and had to be defined as "unattended" applications. The failure mode was often a timeout or connection reset, with logging scattered across the ZPA Admin portal and the connector logs, making initial diagnosis time-consuming.
* **User Experience for Non-Standard Ports:** While web traffic (TCP/80, 443) transitioned smoothly, user-initiated connections to internal resources on arbitrary ports (e.g., SSH, RDP, database clients) required the ZApp connector's "Application Session" to be explicitly established beforehand. This was a significant change management hurdle for our developer and operations teams, who were accustomed to direct connectivity via VPN or ZIA's transparent proxy. The learning curve impacted productivity for several weeks.
The reporting and visibility shift has also been substantial. ZIA's reporting was heavily geared toward web traffic categorization and threat analysis. ZPA's analytics are focused on application access, user-to-application relationships, and segmentation policy efficacy. While powerful, this required us to rebuild several operational dashboards from scratch and establish new baselines for "normal" access patterns. The API integration for pulling audit logs also differs, necessitating updates to our SIEM ingestion workflows.
In conclusion, the migration is operationally stable now, but the three-month post-migration period was marked by higher-than-anticipated support tickets and engineering intervention. The benefits of zero-trust network access are becoming visible, but the path was not a simple "lift-and-shift." Organizations planning a similar transition must allocate resources for deep discovery of all connectivity patterns—especially machine-to-machine and legacy systems—and prepare for a change in administrative mindset from managing network rules to governing application access policies.
Andrew Brown, senior security architect at a 1200-person financial services firm. We've had ZIA in prod for five years, and tried to switch to ZPA last year for a branch office.
**Cost Creep:** ZIA runs about $7-9/user/month for our committed volume. Moving to ZPA added a $3/user "connector" fee for the server side, plus extra for "advanced" app segments. Our quote ballooned 40%.
**Internal App Scrape:** You nailed it. If your app doesn't have a proper FQDN and a clean auth flow, ZPA just blocks it. We found 18 "legacy" reporting tools and internal portals that broke. The "fix" was either a DNS alias project or buying Zscaler's "Digital Experience" module to debug it.
**Performance Drop:** ZIA proxies can cache. ZPA doesn't. Our internal SharePoint site load times went from ~1.2s to ~3.5s for remote users because every asset traverse the connector.
**Support Shift:** ZIA support is a ticket queue. ZPA "requires" you to use their "Technical Account Manager" for anything complex. If your TAM is overloaded, you wait. We waited two weeks for a routing tweak that ZIA would have fixed in a day.
I'd keep ZIA for a mostly remote workforce needing general web access. I'd only pick ZPA if you have a tiny, specific set of cloud apps (like less than 10) and your internal network is already modernized. Tell us your count of legacy internal apps and whether you have a dedicated Zscaler TAM already.
—aB
Yikes, the cost creep is real! We saw something similar, but for us the bigger shock was the internal app piece. It wasn't just about FQDNs, either. We had a handful of old, simple tools that used IP-based bookmarks. ZPA just laughed at us.
That performance hit on SharePoint is brutal, and really highlights the model shift. What about other SaaS apps, like your CRM or email? Did you notice any latency there, or was it mostly isolated to on-prem stuff?
Words matter