Comparison Guide

NSX-T, Cisco ACI, or open EVPN/VXLAN: a fabric decision, not a feature checklist

Most organizations that reconsider NSX-T do it for one reason: the Broadcom-era licensing bill. That reason gets you out the door, but it does not tell you what to build next. Leaving NSX-T is a hypervisor and licensing decision. Choosing what replaces it as your network virtualization and segmentation model is a separate, architectural decision, and it is the one most exit conversations skip.

This guide compares the three realistic paths: staying on NSX-T's proprietary overlay, moving to a different proprietary controller model in Cisco ACI, or adopting open standards-based EVPN/VXLAN on merchant-silicon switching. None of the three is wrong in every environment, and the point here is to place your environment against the dimensions that predict long-term regret: licensing exposure, operational model, automation fit, segmentation parity, and how each path behaves inside a Broadcom-driven migration timeline.

⏱ 15 min read Vendor-neutral | Architecture-focused | Operations-tested

Key Takeaways

  • NSX-T and Cisco ACI are both proprietary controller-based overlays; leaving one for the other trades one licensing and lock-in model for a different one, not for lock-in relief.
  • Open EVPN/VXLAN on merchant silicon decouples the overlay from any single controller vendor, at the cost of assembling segmentation and automation tooling yourself instead of buying it as a bundled policy engine.
  • Cisco's Nexus One initiative is converging ACI and NX-OS VXLAN EVPN under one Nexus Dashboard management plane, which narrows the operational gap between the two but does not remove Cisco as the controller vendor.
  • Broadcom ended new perpetual VMware licensing in December 2023 and folded NSX into the VMware Cloud Foundation bundle; renewal pricing pressure is the forcing function here, and it should not be the only input into the decision.

The Gap Nobody's Exit Strategy Guide Closes

A VMware exit strategy guide tells you how to move compute off vSphere, and correctly flags NSX-T as a major dependency needing its own remediation track. What it does not do is tell you what replaces NSX-T's network virtualization and microsegmentation role. That is a different decision with different tradeoffs, and conflating the two produces bad outcomes.

  • Teams treat leaving NSX-T and adopting EVPN/VXLAN as the same decision, when EVPN/VXLAN is one of three legitimate destinations, not the automatic default
  • Cisco ACI gets shortlisted by name recognition rather than by whether APIC's operational model fits the team that will run it day to day
  • Segmentation policy built over years in NSX-T's distributed firewall does not port automatically to any destination, and the re-authoring effort is consistently underestimated
  • Automation and IaC maturity gets evaluated against vendor marketing claims instead of the team's actual Terraform, Ansible, or GitOps practice
  • The Broadcom renewal clock pressures teams to decide fast, which favors whatever platform the incumbent reseller already sells

Five Dimensions That Actually Predict Which Path Fits

Feature matrices make NSX-T, Cisco ACI, and EVPN/VXLAN look more similar than they are, because most of what a controller-based platform sells is the packaging around a fabric, not the fabric itself. These five dimensions are where the real differences surface.

Lock-In and Licensing Exposure

NSX-T ships inside the VMware Cloud Foundation bundle, priced per core alongside vSphere, vSAN, and Aria, whether you use all of it or not. Cisco ACI licensing is per-device across Essentials, Advantage, and Premier tiers tied to Nexus 9000 hardware and APIC, trading one vendor's subscription for another's. Open EVPN/VXLAN separates the licensing question from the fabric entirely: you buy switching hardware and, optionally, a fabric management layer, with no single vendor holding the overlay hostage to a compute or storage bundle.

Operational Model and Skills

NSX-T and ACI both centralize policy in a controller, NSX Manager or APIC, with its own object model, upgrade cadence, and failure domain. Open EVPN/VXLAN pushes control-plane state into standards-based BGP EVPN, which a team with existing routing skills can operate without a proprietary abstraction layer, but with no single vendor support queue to call when the fabric behaves unexpectedly.

Automation and Infrastructure as Code Fit

ACI and NSX-T expose REST APIs and Terraform providers, but their object models, EPGs and contracts for ACI, groups and distributed firewall rules for NSX-T, are proprietary abstractions your IaC has to model explicitly. EVPN/VXLAN configuration on merchant silicon maps closer to standard interface, VLAN, and BGP primitives, which is faster to template across multi-vendor Nexus 9000, Arista, or white-box environments.

Segmentation and Microsegmentation Parity

This is where NSX-T and ACI still have a real edge. NSX-T's Distributed Firewall and ACI's EPG-and-contract model both enforce microsegmentation at the hypervisor or leaf without a separate security product. Open EVPN/VXLAN gives you segmentation through VRFs and VNIs, but application-aware microsegmentation that stops lateral movement inside a subnet needs a separate control point layered on top.

Migration Context in a Broadcom-Era Exit

If your NSX-T exit is licensing-driven rather than a technical failure of NSX-T itself, the honest question is whether you are solving a licensing problem or a networking problem. Cisco ACI solves neither; it keeps a proprietary controller model and adds a second vendor relationship. Open EVPN/VXLAN solves the licensing exposure but requires rebuilding segmentation policy and, likely, new BGP EVPN operational depth before cutover.

Which network virtualization model fits your environment after an NSX-T exit?

Three realistic destinations follow an NSX-T reconsideration. Each carries a different licensing, operational, and segmentation profile.

Stay Proprietary, Same Vendor: NSX-T (Retained or Re-Licensed)

Keeping VMware's overlay and distributed firewall in place, re-licensed under VMware Cloud Foundation, rather than migrating the network virtualization layer during a broader VMware exit.

Best fit: Organizations whose primary Broadcom pain point is compute and storage licensing, not NSX-T itself, with deep NSX policy investment that would be costly to re-author on another platform this renewal cycle.

Tradeoffs: Does not reduce Broadcom licensing exposure, since NSX ships inside the VCF bundle, and ties your network virtualization roadmap to VMware's subscription terms indefinitely.

IVI recommendation: We treat this as a valid bridge, not a destination. It buys time to re-architect segmentation deliberately instead of under renewal-clock pressure, but it should carry an explicit sunset date.

Stay Proprietary, Different Vendor: Cisco ACI (APIC-Managed)

Replacing NSX-T's overlay and segmentation model with Cisco's APIC-controlled fabric on Nexus 9000 switching, keeping a centralized policy controller but changing which vendor owns it.

Best fit: Organizations that want EPG-and-contract microsegmentation parity with NSX-T, have or will build Cisco-specific operational skills, and are comfortable running fabrics through APIC's declarative policy model.

Tradeoffs: Trades one proprietary controller and licensing model for another, with per-device costs tied to Nexus 9000 refreshes, and Cisco's own roadmap is converging ACI into NX-OS VXLAN EVPN under Nexus Dashboard.

IVI recommendation: Fair where segmentation parity is non-negotiable and the team already runs Cisco data center gear. We are candid that Cisco's Nexus One direction signals ACI is not where Cisco is investing its differentiation going forward.

Open Standards, Merchant Silicon: Open EVPN/VXLAN

Building the overlay on standards-based BGP EVPN control plane and VXLAN data plane across merchant-silicon leaf-spine switching, with no proprietary controller mediating fabric state.

Best fit: Organizations exiting NSX-T primarily to remove licensing exposure and lock-in, with an existing or attainable BGP skill set, where VRF and VNI segmentation plus a separate microsegmentation tool covers the security requirement.

Tradeoffs: No single vendor bundles microsegmentation the way NSX-T or ACI do, the team owns correctness of the BGP EVPN design directly, and migrating years of NSX-T tag-based policy into VRF and VNI constructs is a genuine re-architecture.

IVI recommendation: This is where our data center practice spends most of its time, and we say so plainly: for licensing-driven NSX-T exits, open EVPN/VXLAN on merchant silicon usually resolves the problem rather than relocating it. It is the wrong call for a team unwilling to build BGP EVPN depth.

How to Work Through This Decision

Run these steps in order before you shortlist a platform. Each one changes the answer to the next.

Separate the licensing problem from the networking problem

Write down what re-licensing NSX-T under VMware Cloud Foundation actually costs versus what you are trying to avoid. If the number driving urgency is compute and storage licensing rather than NSX-T's networking behavior, say so before evaluating alternatives, since that changes whether Cisco ACI, a different licensing model wrapped around the same architectural pattern, solves anything.

Inventory what your segmentation policy actually enforces today

Document the NSX-T DFW rules, tags, and security groups in production. Split them into network-layer segmentation, which VRFs and VNIs can replicate, versus application-aware rules, which need ACI's contract model or a dedicated microsegmentation product layered on open EVPN/VXLAN.

Score your team's operational skill set honestly

BGP EVPN depth is learnable but not free. A team that has run exclusively through NSX Manager or APIC's API will need real training time before an open EVPN/VXLAN fabric is production-safe. If that runway does not exist before your renewal date, build a bridge period into the plan.

Route the two decisions into the right IVI engagements

If NSX-T is the dependency being remediated as part of a broader VMware exit, that work follows our NSX-T exit strategy and network virtualization migration paths guide. If the destination is open EVPN/VXLAN, the fabric design detail lives in our guide to EVPN/VXLAN as a modern overlay, and delivery runs through our leaf-spine EVPN services. This guide's job is only to help you pick the destination before you open either one.

Who This Guide Is For

  • Data center architects and network leads reconsidering NSX-T as part of a Broadcom-driven VMware exit, who need the network virtualization decision separated from the hypervisor decision
  • Teams evaluating Cisco ACI by name recognition who have not yet stress-tested whether APIC's operational model and per-device licensing fit their environment
  • Organizations with mature BGP skills considering whether open EVPN/VXLAN on merchant silicon can carry their segmentation requirements without a proprietary controller
  • Infrastructure leaders who need a neutral, non-vendor-briefing framework for an internal architecture review

Related Resources

FAQs

Frequently Asked Questions

If we're already exiting NSX-T for licensing reasons, doesn't that mean we should default to open EVPN/VXLAN?

Usually, but not automatically. Licensing exposure is the strongest argument for EVPN/VXLAN, since it removes the single-vendor bundle problem. But if your segmentation policy depends heavily on hypervisor-integrated microsegmentation that a network-layer overlay cannot replicate, that requirement has to be solved first, either by keeping a controller-based platform or by adding a separate microsegmentation product to an EVPN/VXLAN fabric.

Is Cisco ACI actually going away?

Cisco has not announced an end of life for ACI, but its Nexus One initiative is converging ACI and NX-OS VXLAN EVPN under a single Nexus Dashboard management plane, with native Splunk integration and AgenticOps for reasoning-driven multi-domain troubleshooting across both fabric types. Cisco also announced an end-of-sale for Nexus Dashboard and APIC M6 appliances effective June 18, 2026. Read that as Cisco's investment shifting toward unified fabric management, not as ACI disappearing overnight.

Can we migrate NSX-T's distributed firewall rules directly into Cisco ACI contracts or EVPN/VXLAN VRFs?

Not as a one-to-one syntactic conversion. Both destinations require re-authoring policy intent, not translating rule syntax. ACI's EPG-and-contract model is the closer conceptual match to NSX-T's group-based rules, but even that migration is a redesign exercise. Plan for a policy re-authoring phase regardless of which path you choose.

How long does this architecture decision typically take before implementation starts?

For organizations with a documented segmentation inventory and a clear read on their Broadcom renewal timeline, the assessment and decision phase generally runs four to six weeks, covering the licensing-versus-networking exercise, the segmentation inventory, and the skills assessment in this guide's process steps, before any fabric design or migration work begins.

Need help choosing the right overlay architecture?

IVI's network architects have designed and deployed all three approaches across hundreds of data centers. We can help you evaluate your requirements, compare vendor proposals, and design an overlay strategy that aligns with your operational model and business objectives.

Schedule an Architecture Review