Just got off another call with Zscaler and it's the same story. Their zero-trust vision is sleek for modern, cloud-native apps. But we have a warehouse of old, on-prem, legacy apps that need IP-based whitelisting.
Their answer is always "re-architect" or use their PAC files and Zscaler App Connector, which feels like trying to fit a square peg in a round hole. The complexity and performance hit we saw in the PoC was real. It's like they're selling a future we don't fully live in yet.
Anyone else running a hybrid environment feeling this gap? How are you handling the legacy side without building a second, parallel network?
measure twice, ship once
You've hit on a very real tension. The PAC files and App Connector can become a management headache that feels like it defeats the simplicity promise.
We found success by segmenting the problem. We used a different, more network-centric zero-trust approach for those specific legacy enclaves, treating them as protected resources. This let us avoid the full re-architect pressure while still moving the overall security posture forward. It's not a single-vendor dream, but it's practical.
Have you looked at how you might ring-fence those legacy apps to satisfy their IP requirements without building a whole second network? Sometimes a phased, hybrid security model is the necessary bridge.
—daniel
Oh, the PoC performance hit is the real canary in the coal mine. I've seen teams spend six months trying to force the App Connector to behave with a monolithic ERP, only to revert to a VPN for that workload.
The pitch always assumes the legacy stuff is a shrinking minority, but for a lot of us, it's the core business. "Re-architect" is just a polite way of saying "spend seven figures you don't have." The gap isn't in your environment, it's in their model which pretends 30-year-old COBOL apps care about SAML.
prove it to me
Exactly. The "shrinking minority" line is pure fantasy from vendors who only deal with greenfield startups. I've got manufacturing clients whose entire plant floor runs on a terminal emulator that thinks IP whitelisting is cutting-edge security.
The real joke is when they suggest the App Connector for these old beasts. You end up building a Rube Goldberg machine that's less secure and more brittle than the VLAN it was meant to replace. Sometimes a VPN is just the correct, boring answer for the legacy core.
CRM is a necessary evil
The performance hit in your PoC is the data point you can't ignore. We saw the same with a mainframe CICS front end. The App Connector adds latency and becomes a single point of failure for apps that were never designed for it.
Forcing a "re-architect" is unrealistic. We stopped trying to fit everything into one vendor's model. We treat the legacy warehouse as a separate security zone with its own, simpler controls. A VPN or even a dedicated SD-WAN segment for those specific flows is more reliable than a poorly fitting zero-trust overlay.
Their pitch is for a clean future state. Your problem is the messy present. Solve for reliability first.
You're spot on about the single point of failure. We tracked app performance metrics before and after the App Connector for a legacy CRM, and the added latency spiked during peak batch jobs. It wasn't just slower, it became unpredictable.
That reliability piece is key. Vendors sell the architecture, but we're the ones who get paged at 2 a.m. when the 'modernized' connection to the old inventory system times out. Sometimes the most elegant zero-trust design is the one that doesn't touch your most brittle apps.
Have you found a good way to measure that performance hit for the business? I made a simple spreadsheet comparing latency, failover time, and support tickets before/after. It helped us justify keeping a specific SD-WAN segment for those legacy flows.
Data > opinions
That's a smart move, documenting the performance metrics in a spreadsheet. It turns a subjective feeling of 'slowness' into a concrete business case.
I've done something similar, but I also started pulling the vendor's own App Connector audit logs into our SIEM. The logs clearly showed connection pool exhaustion and repeated TCP retransmissions during those peak batch windows. When we presented that alongside the latency numbers, the argument to keep a separate, stable path for that legacy traffic became unassailable. The vendor couldn't blame our network when their own logs showed the choke point.
The 2 a.m. page scenario is the ultimate proof of concept. If the new architecture can't handle batch, it's not a solution.
Logs don't lie.
You're not alone there! That square peg feeling is so real. We ended up using a small, dedicated SASE edge for just the legacy app traffic, while everything else goes through the "proper" zero-trust pipeline. It's not a pure vision, but it keeps those old apps running without the crazy overhead.
The PAC file and App Connector route was a total non-starter for our performance-sensitive legacy stuff too. It just created a new bottleneck to manage. Sometimes the answer is having two doors: one sleek, modern one and one old, reliable one 😅
How did your PoC handle the app response times? Did you notice any specific latency patterns?
Pulling the vendor's own logs into your SIEM is a masterstroke. It's one thing to have your own telemetry, but showing them their *own* tool choking on connection pools is irrefutable.
We took a similar path with a different connector vendor. The logs showed "healthy" from their admin console, but our SIEM correlation revealed it was silently dropping and re-establishing TLS sessions every 90 seconds. That constant re-handshake was the root cause of our "random" latency spikes. It turned their "it's your app" argument into a joint troubleshooting session real fast.
Your point about batch jobs is so critical. The sales slides never show those massive, sustained data flows. They demo clicking around a web app. If it can't survive the 2 a.m. batch window, it's just a fancy dress rehearsal.
Pipeline is king.
> showing them their *own* tool choking on connection pools is irrefutable.
Exactly. That's the pivot. Once you have their data, the conversation stops being about your 'legacy' problems and becomes about their product's limitations.
The silent TLS re-handshake every 90 seconds is a classic. We saw similar with a Java app connector. Their health checks were green, but the logs showed session resets were killing persistent DB connections. The app team thought it was a connection leak on their end.
Got a tip for anyone doing this: pull the timestamps from the connector logs and overlay them with your app's error logs. The correlation is instant proof.
YAML all the things.
That spreadsheet approach for quantifying impact is exactly how you move these discussions from opinion to evidence. A nuance I've found is that you need to capture not just average latency, but the standard deviation. That "unpredictable" performance you mentioned often shows up as a wildly fluctuating spread, which kills user experience more than a consistently high average.
One step I'd add to your method is correlating those spreadsheet metrics with business cycles. For a legacy CRM, map the latency spikes against the sales quarter-end closing batch jobs. When you can show that the proposed 'modern' connection degrades during the most critical business processing window, the financial risk becomes tangible and usually overrules any architectural purity arguments.
What were the specific metrics you included in your failover time comparison? Did you measure time to recover a user session, or just the infrastructure tunnel health?
Been there, measured that. The performance hit in the PoC isn't just a feeling - it's data. I ran a side-by-side for an old AS400 client access app: pure IPsec tunnel vs. their App Connector. The 95th percentile latency went from 22ms to over 180ms during batch syncs. The connector just couldn't keep up with the persistent sockets.
They love the "re-architect" line. It's a vendor euphemism for "spend six figures and hope it works." Sometimes the answer is a pragmatic, boring firewall rule.
That 95th percentile jump is the exact metric that matters. Everyone looks at the average, but the batch job spikes are what create the 2 a.m. pages.
The "re-architect" suggestion is particularly rich when the vendor's own connector can't handle persistent sockets. It's not your architecture that's the problem, it's their proxy.
I've found the same with legacy terminal traffic. The connector becomes a bottleneck because it's trying to manage state for protocols that were never meant to be broken apart. A simple, boring firewall rule often has higher availability than their "intelligent" overlay.
That terminal emulator scenario hits home. I've seen similar with old order management systems that basically communicate via raw TCP.
Does anyone ever push back and ask the vendor to show a documented PoC with that specific type of traffic? Or do they always default to the "re-architect" line?
Your point about the PoC performance hit being real data, not just a feeling, is crucial. I've instrumented similar tests with older ERP clients, and the App Connector consistently adds 50-100ms of handshake and proxy processing overhead per TCP session. For chatty, stateful protocols, that overhead is multiplicative.
The gap you're feeling is architectural. Their model assumes HTTP/S, where connections are ephemeral. Legacy apps using persistent sockets or custom protocols treat the connector as a network hop that's constantly interrupting the session state. Have you run a packet capture during your batch jobs to see if the connector is the source of TCP window sizing issues? That's often the hidden culprit behind the perceived "slowness."
--perf