Breaking the Broadcom Shackles: Is Escaping NSX, Avi & vSAN Actually Viable?
When you've built your entire operational DNA around VMware's holy trinity, leaving isn't a migration — it's an architectural divorce.
Let's be honest with ourselves. The question everyone is asking post-Broadcom acquisition isn't "should we leave VMware?" — it's "can we actually leave, given how deep we are?" If you're running the full holy trinity of NSX, Avi Networks, and vSAN, you're not just using software. You've woven Broadcom's proprietary logic into every layer of your stack.
The frustration is completely understandable. Broadcom's new per-core VCF pricing model has landed like a grenade in most infrastructure budgets. But pricing anger and actual migration viability are two very different conversations — and conflating them leads organisations to make rash decisions they'll regret for years.
So let's have the honest conversation. Component by component.
The stickiest trap: NSX & Avi Networks
If you had to rank the VMware components by "escape difficulty," NSX belongs at the top. It's not just a network overlay — it's where your entire security posture lives. Micro-segmentation rules, distributed firewall policies, VXLAN/Geneve encapsulation logic, and your east-west traffic inspection are all baked into NSX constructs that exist nowhere else in the same form.
For Avi specifically, most organisations looking to exit are reverting to F5 BIG-IP or NGINX as a replacement. Both are credible. Neither gives you the tight "one-pane-of-glass" integration that VCD provided with Avi sitting natively within the platform. You are trading operational simplicity for vendor independence — and that trade-off has a real cost in engineer hours.
The most technically interesting alternative gaining traction in the Kubernetes-forward space is Cilium with eBPF for networking and security policy enforcement. It's genuinely powerful, but it requires a meaningful architectural pivot toward container-native thinking. If your workloads are still primarily VM-based — and in most enterprise environments they are — Cilium isn't your NSX replacement. Not yet.
The storage wall: vSAN is a data migration project in disguise
People often underestimate vSAN migration because it looks like a software problem. It isn't. vSAN is software-defined storage running on your local server disks, which means your data is physically distributed across your ESXi hosts in a proprietary format. To leave, you need somewhere to put the data first.
Physical SAN as swing space
Buy NetApp or Pure Storage as a temporary migration target. Capital-intensive and requires major procurement lead time.
Host-by-host HCI migration
Migrate workloads incrementally to Nutanix AOS. Operationally gruelling and typically spans 12–18 months minimum.
Stay put, reduce tier
Retain vSAN but negotiate down to the minimum required licensing tier. Reduce costs without the migration risk.
The brutal reality is that most organisations aren't doing a full vSAN exit. They're staying put because the capital cost of a migration — both hardware and engineering time — frequently exceeds the increased Broadcom licensing cost for the first three years. The maths doesn't work for a full rip-and-replace until you're operating at meaningful scale.
The platform parity problem
This is the dimension that gets the least attention in migration conversations, and it's arguably the most important one for service providers running VCD environments.
VCD is enterprise-polished in a way that most alternatives simply aren't. Tenant self-service portals, billing integration, service catalog management, role-based access across multiple organisations — VCD handles all of this in a way that feels coherent because it was designed as a complete platform. The sum is greater than the parts.
OpenStack is a similar story — powerful, flexible, cloud-native by design, but it carries substantial operational overhead. Proxmox is excellent for smaller environments but simply isn't built for the multi-tenancy and scale that VCD handles natively.
The middle ground: strategic shrinking
Most organisations that are handling this well aren't planning a 100% VMware exit. They're pursuing what I'd call strategic shrinking — a deliberate, phased approach to reducing VMware's footprint and licensing exposure without the risk of a full platform migration.
- Freeze the VMware footprint Stop growing the VCF/VCD environment. No new compute added under Broadcom licensing. Existing capacity becomes legacy.
- Route new workloads elsewhere Any new customer deployment, new internal project, or greenfield service goes onto Nutanix or a KVM-based platform from day one.
- Negotiate the legacy island down Keep the NSX/vSAN stack for applications that are genuinely too complex to migrate, but work aggressively on getting your licensing tier to the minimum viable configuration.
- Build migration competency gradually Use lower-stakes workload migrations to build your team's capability on the target platform before tackling the genuinely difficult stuff.
The verdict: it depends entirely on your scale
| Organisation type | Full exit viable? | Why |
|---|---|---|
| Small / mid-tier MSP Under ~500 cores |
Unlikely | Migration cost (hardware + engineering time) typically exceeds the Broadcom tax for the first 3 years. The maths don't work. |
| Mid-market enterprise 500–2,000 cores |
Strategic shrink | Partial exit viable. Freeze and redirect new workloads. Negotiate the legacy core down. |
| Large enterprise / global provider 5,000+ cores |
Yes, long-term | At this scale, the Broadcom tax is high enough that hiring a dedicated OpenStack or Nutanix engineering team becomes the cheaper long-term play. |
What should you actually do right now?
Before making any platform decisions, do the one thing most organisations skip: build a proper total cost of ownership model. Not just the licensing delta — the full picture. Engineering time to rebuild NSX equivalent security posture. Data migration hardware and project cost. Training and upskilling on the target platform. Operational tooling gaps you'll need to fill.
When you do that analysis honestly, the decision usually becomes clearer. For smaller providers, the answer is often "negotiate hard with Broadcom and reduce your licensing tier aggressively." For larger ones, it's "start the journey now, because the longer you wait, the more the dependency deepens."
Either way, the worst strategy is paralysis. The organisations that will be in the best position in three years are the ones that made a deliberate choice — exit, shrink, or stay — with eyes open, not the ones still waiting to see how the pricing model evolves.
Broadcom is betting you'll wait. Don't prove them right.
Are you currently evaluating a VMware exit strategy?
I'd be interested to hear where you are in the process — whether you're still on a legacy perpetual/VCPP model, or you've been quoted on the new per-core VCF pricing. Drop your situation in the comments below.
No comments:
Post a Comment