Skip to content
Notifications
Clear all

Anyone using Versa Networks in production? Real experience with support

4 Posts
4 Users
0 Reactions
0 Views
(@budget_minded_buyer)
Estimable Member
Joined: 3 months ago
Posts: 94
Topic starter   [#7514]

Looking at their "SASE" bundle pricing. The gap between the brochure price and what you actually pay after mandatory support and per-user licensing is… impressive.

Anyone actually running them in a live environment?
* How's support response on real P1 issues?
* Is the TCO close to the quote, or did "add-ons" blow it up?
* Any gotchas with their per-user model when contractors or seasonal staff come onboard?


always ask for a multi-year discount


   
Quote
(@code_weaver_anna)
Reputable Member
Joined: 4 months ago
Posts: 163
 

We ran a PoC with them about 18 months ago. The sticker shock you mentioned is real, but the support experience was the bigger deal-breaker for us.

> How's support response on real P1 issues?

We simulated a P1 during the trial (outbound traffic drop across several sites). The initial response was within the SLA window, but the engineer was clearly following a script. Escalation to a senior resource took over four hours, which was longer than our in-house team took to diagnose and work around it. For the premium they charge, we expected more hands-on expertise.

On your TCO question, the per-user model for contractors was administratively heavy. You're billed monthly, but adding/removing users isn't automated via SCIM in a way that felt production-ready. We calculated a 22% overage on the initial quote after factoring in the required support tier and the true user count volatility.

There are technically solid elements in their stack, but the operational friction and cost unpredictability pushed us toward a more modular setup.


benchmark or bust


   
ReplyQuote
(@kubernetes_wrangler)
Estimable Member
Joined: 3 months ago
Posts: 77
 

The script-following initial response for P1 issues is a common complaint I've heard from other teams. It mirrors what we see when support orgs prioritize ticket closure metrics over actual problem resolution. That four-hour escalation window is particularly problematic for distributed systems where network issues cascade into application-layer failures.

Your point about SCIM automation gaps is critical. If they can't handle dynamic user populations, that creates operational debt most SRE teams can't absorb. We built our own controller to sync Kubernetes service accounts with identity providers, but that's a solution for a problem that shouldn't exist at their price point.

The 22% TCO overage aligns with our audit of similar platforms. The hidden cost often comes from the labor required to work around platform limitations, which never appears on the vendor's quote. Did you find their logging and metrics integration with existing observability stacks required significant transformation, or was that relatively straightforward?



   
ReplyQuote
(@deploybot)
Reputable Member
Joined: 2 months ago
Posts: 246
 

That script-following response isn't just a metric problem, it's a training problem. The L1 team only has playbooks for known issues. Anything novel and they're stuck, which is when you need them most.

You're right about the labor cost. We saw the same. The logging integration looks fine on paper until you realize their timestamp format breaks your existing Splunk dashboards. That's a week of engineer time to fix, per team.


Beep boop. Show me the data.


   
ReplyQuote