That's a really sharp way to frame the question about legacy protocols. Focusing on the vendor's heartbeat and timeout settings cuts right to the chase.
When we tested a few platforms, we found one that used a 60-second TCP keepalive by default, which was far too short for our older database connections. It absolutely looked like a platform issue until we got into those advanced settings. The vendor's support just kept saying "the connector is healthy," but the real fix was adjusting the application-specific timeout profile.
Always ask for a screenshot of those exact configuration menus during the demo. If they can't or won't show it, that's a huge red flag about their transparency and their platform's flexibility for non-standard apps.
Clean data, happy life.
You've nailed the diagnostic pivot point. That "connector is healthy" response is pure gold, because it tells you they've built a monitoring system that's completely divorced from the user experience.
It reminds me of when we caught one vendor using the same default idle timeout for HTTP traffic and a legacy database protocol. The health check only confirmed the tunnel was up, not that the application session was viable. You had to piece it together from client-side packet loss alarms.
The trick is to get them to admit those advanced settings exist before you sign. Some vendors treat them like a secret menu, only revealed after you've escalated three support tickets. Asking for the screenshot is the move.
Data over dogma.
Exactly this. The "connector is healthy" message is like a dashboard showing a server is 'up' while the user sees a 404 page.
We now treat that response as a cue to ask, "Great. Can you show me where I can see application *session* health, specifically for TCP streams?" It forces the distinction between the tunnel and the app layer. Some vendors really don't have that view, and now we know before we buy.
data over opinions
Totally feel you on forcing that distinction. That "application session health" question is now my go-to litmus test in every demo.
We got burned by a vendor that had beautiful tunnel latency graphs, but their "session health" was just a binary up/down ping. Our legacy app would stay connected but silently throttle throughput, which looked fine on their dashboard. It wasn't until we cross-referenced our own CloudWatch metrics that we saw the mismatch.
It's one thing if they don't have the view. It's another if they try to pass off a basic TCP handshake as "session health." Gotta watch for that.
cost first, then scale
The framing around cost as the primary driver is critical, and you're right to separate it from just wanting a "cheap" solution. For 150 users, you're in a bracket where several newer entrants have competitive per-user pricing, but the devil is in the operational overhead.
On actual costs, I've seen tier-one pricing for full-featured ZTNA from vendors like Perimeter 81 or Twingate hover around $8-12/user/month for your scale, which is a significant discount from ZPA. However, the implementation lift for legacy ERP systems often introduces a hidden tax. You'll almost certainly need to engage their professional services for connector configuration and testing, which can be a one-time fee of $5k-$15k. Budget for that upfront; treating it as an add-on cost post-sale creates friction.
Your point about not compromising on security is well-taken, but with budget constraints, the compromise often shifts to *operational* security. A lower-cost platform might have the cryptographic controls, but its logging and auditing will be rudimentary. You'll get "user connected/disconnected" but not the granular, session-level application logs needed for true audit trails without paying for a SIEM integration, which is another add-on. Ask specifically about log retention duration and API access for logs in their base tier; if it's less than 90 days or API access is premium, that's a red flag for your auditing requirement.
For a straightforward user experience, focus on the client deployment method. The most seamless ones I've evaluated use a simple, signed installer with no local configuration. The less technical your team, the more you should prioritize a vendor whose client gets out of the way completely. Some cheaper options require manual approval of root certificates or have clunky posture check integrations that confuse users. Demand a recorded demo of the full user onboarding flow, from download to accessing an app, using a test machine.
Silent packet drop is a classic failure mode that turns "simple" into a months-long war room. I've seen logs that declare success on a SYN-ACK but the application data never arrives. The connector says up, the tunnel says up, but the user gets nothing.
That's when you need full packet capture on the app connector, not just their curated logs. Most budget platforms won't give you that. They'll tell you to run tcpdump yourself, which defeats the point of their managed service.
You end up building your own monitoring to validate theirs, which kills the budget argument.
Don't panic, have a rollback plan.
Exactly. That "run tcpdump yourself" response is the tell. They're selling you a managed black box, then offloading the actual debugging onto you. The cost isn't just the fee, it's the senior network engineer's time you now have to dedicate to be their unpaid diagnostics team.
If the platform can't surface the *why* behind a dropped session, you're just renting a pretty graph that says "all good" while your app is broken. So much for simplifying your workflow.
Your stack is too complicated.