If you're planning a new leaf-spine fabric in 2026, the more interesting question is no longer “ACI or not?” It is “how much of my future operating model depends on open EVPN/VXLAN primitives versus a controller-specific abstraction layer?”
That shift is why more teams are standardizing on NX-OS VXLAN EVPN for new data center builds, even when they stay on Cisco hardware.
This is not a formal ACI end-of-life announcement. Cisco has not published that. But the direction is getting clearer: ACI capabilities are being converged into a broader Cisco data center story centered on Nexus Dashboard, open EVPN/VXLAN standards, and a more unified fabric model.
If you run ACI today, this does not mean rip and replace. It does mean the default choice for the next build, expansion, or refresh increasingly looks like EVPN.
What changed in Cisco's direction
Cisco's Nexus One Fabric announcement is the strongest public signal.
The important part is not the branding. It is the architecture:
- ACI and NX-OS fabrics are being pulled under a shared management plane
- Cisco keeps emphasizing open VXLAN EVPN standards
- The operational center of gravity is moving toward Nexus Dashboard, not a standalone APIC-only worldview
That matters because it changes the long-term skills and operating model that teams should invest in.
What operators are seeing in the field
The pattern showing up in renewals is pretty consistent:
- An existing ACI environment comes up for refresh
- The team re-evaluates day-2 operations, staffing, and automation
- EVPN/VXLAN on NX-OS becomes the front-runner
- The organization keeps Cisco switching, but drops the ACI-specific policy model
Why? Mostly because EVPN feels closer to how infrastructure teams already work.
Instead of forcing every workflow through tenants, application profiles, EPGs, and contracts, EVPN lets teams reason in more familiar primitives:
- BGP EVPN control plane
- VRFs and VNIs
- VTEPs and route types
- route-policy and automation tooling that transfers across vendors
That makes troubleshooting, hiring, cross-training, and automation easier.
Why EVPN is winning new builds
1. The skills transfer better
ACI expertise is valuable, but it is tightly coupled to one product model.
EVPN expertise transfers across vendors and roles. If an engineer understands route type 2 and type 5 advertisements, symmetric versus asymmetric IRB, multihoming, and how BGP policy shapes the overlay, that knowledge carries into Cisco, Arista, Juniper, and Nokia environments.
That is a much safer bet for teams building a platform they expect to keep for years.
2. The operating model is easier to explain
ACI is powerful, but many teams still experience it as an extra abstraction layer between the engineer and the fabric.
EVPN on NX-OS is not simple, but it is more legible. When something breaks, engineers can usually walk the failure through standard networking constructs:
- underlay reachability
- BGP EVPN adjacency state
- VNI to VRF mapping
- anycast gateway behavior
- route import and export policy
That makes incident response faster, especially for teams that do not have deep ACI specialists on call.
3. Automation is less vendor-shaped
ACI has a strong API story, but it is still the ACI object model.
EVPN fabrics on NX-OS fit more naturally into mixed automation stacks using:
- Ansible
- Terraform
- model-driven interfaces
- reusable BGP and policy templates
For teams trying to standardize on infrastructure-as-code patterns, that matters more than marketing slides.
4. Multivendor is no longer hypothetical
Even teams that are all-Cisco today are planning for optionality.
AI fabrics, GPU clusters, and fast-changing east-west traffic patterns are pushing data center designs toward architectures where standards-based control planes are easier to defend internally. EVPN gives architects a cleaner story for interoperability and future flexibility.
5. Cisco's own messaging now favors convergence
This is the part many engineers miss.
When the vendor itself starts talking about unified management across ACI and NX-OS fabrics, it is a signal that the old product boundaries matter less than the shared destination. And that destination looks much more like EVPN-centric operations than classic ACI-first thinking.
ACI vs NX-OS VXLAN EVPN, the practical comparison
| Dimension | Cisco ACI | NX-OS VXLAN EVPN |
|---|---|---|
| Day-1 provisioning | Strong for greenfield, controller-led rollout | Strong, but usually more design work up front |
| Day-2 troubleshooting | Can be opaque if the team is not deeply ACI-native | Usually easier to reason through with standard network tools |
| Policy model | Powerful, but proprietary and abstraction-heavy | More explicit, closer to standard routing and switching constructs |
| Automation | Good, but tied to the ACI object model | Better fit for broader IaC and multivendor workflows |
| Hiring and cross-training | Smaller specialist talent pool | Larger transferable skill base |
| Fabric portability | Cisco-specific | Standards-oriented, easier to justify in multivendor plans |
| Long-term direction | Converging into broader Cisco fabric strategy | Increasingly aligned with that strategy |
Where ACI still wins
ACI is not irrelevant.
It still has real strengths:
- strong greenfield experience for teams bought into the model
- mature segmentation and policy constructs
- centralized governance that some organizations genuinely prefer
- existing installed base with operational muscle already built around APIC
If your team already runs ACI well, there may be no business case to move quickly.
The bigger point is this: if you are making a fresh platform choice today, EVPN usually has the better long-term risk profile.
If you're running ACI today, do this next
1. Treat the next refresh as a design decision, not a renewal checkbox
Do not assume “same hardware family” means “same operating model.” Separate the switching decision from the control and management decision.
2. Start labbing EVPN before you need it
Build and break a small fabric. Practice the things your future incidents will actually depend on:
- underlay routing
- EVPN route exchange
- symmetric IRB
- multihoming
- failure testing around spines, VTEPs, and anycast gateways
3. Map ACI constructs to EVPN constructs early
The difficult part of any migration is not syntax. It is intent mapping.
Translate these before a project starts:
- tenants to VRF boundaries
- bridge domains to L2/L3 service design
- EPG policy intent to route-policy, ACL, or segmentation enforcement points
4. Validate your automation assumptions
Many teams discover that their current automation is really APIC workflow automation, not portable data center automation. That is fine, but it should be understood early.
5. Align people and platform together
If the team you have is made of strong CLI, BGP, and systems engineers, EVPN will often create less operational drag than doubling down on a controller-specific operating model.
My take
ACI is not disappearing overnight. But the center of gravity is shifting.
For most new builds, NX-OS VXLAN EVPN is becoming the safer engineering choice because it gives teams:
- a more transferable skill stack
- a more transparent troubleshooting model
- a better fit for automation
- less long-term architectural lock-in
That does not make ACI bad. It just means the default answer has changed.
If you want the original long-form version, the canonical article is on firstpasslab.com.
AI disclosure: This article was adapted with AI assistance from an original FirstPassLab post. The canonical source is linked above, and all technical claims are based on the original article and cited references.
Top comments (0)