33 / 33Cisco ACI

Cisco ACI, supported today and designed for whatever follows it

Cisco ACI support and migration for Canadian data centres, from a team that holds the CCIE.

  • CCIE Data Center-led team
  • ACI, Nexus Dashboard and VXLAN EVPN
  • Canadian data residency
THE WORK

Cisco ACI, three pillars, one operator.

One Canadian team keeps the fabric supported, designs its successor, and runs both. Application Centric Infrastructure, the APIC controllers and the ACI fabric underneath them each age on their own schedule.

  1. 1

    Keep it supported

    The management layer moved and the old controller software ran out of runway. We hold the lifecycle position for every controller, switch and software version you run, track the advisories against them, and keep the patch path current instead of discovering it during an outage.

  2. 2

    Design what follows

    A standards-based fabric you can interconnect to, rather than a cutover cliff. From a recent ACI release there's a supported interconnect to a VXLAN EVPN fabric, with names normalised across the boundary so tenants keep their identity as they cross.

  3. 3

    Run both at once

    Two fabrics live, workloads crossing between them on your schedule. When something breaks at 02:00, escalation reaches an engineer who already knows your policy model rather than a queue asking you to upload the config again.

THE PROOF

Built to last. Evidence over promises.

Cisco has published no ACI end-of-life. It has published one for the tooling around it, and the difference is the whole decision.

IN PRODUCTION

A Canadian fabric with two exits.

We'd been told twice that our fabric was a dead end and once that nothing had changed. SMEnode read the lifecycle notices, showed us which ones were about hardware and which about software, and built the interconnect so the new fabric came up beside the old one. Nothing was stranded. We're moving tenants when it suits us.

SMEnode · Engineering principle
  • CCIE Data Center
  • CCIE Security
  • CCDE Design
  • Canadian data residency
THE DEEP DIVE

Cisco ACI in Canada, made real.

Two things get said about this platform and both are wrong. One is that it's finished. The other is that nothing has changed.

What Cisco has actually published, and what it hasn't.

Start with the notices, because the rumours are louder. There's no end-of-life for the platform itself. What does exist: support for Data Center Network Manager 11.5.x ended in April 2026, NDFC on Nexus Dashboard is its successor, and new NX-OS switch image support goes to that successor only (source: Cisco, DCNM 11.5.x end-of-sale and end-of-life announcement). Separately, the Nexus Dashboard and APIC M6 appliances carry their own end-of-sale notice, which is controller hardware rather than a product decision (source: Cisco). Confuse the two and you either panic early or miss a real support deadline.

The direction changed, and it works in your favour.

The management layer now drives ACI and standards-based fabrics side by side rather than one or the other, and there's a supported interconnect between an ACI fabric on a recent release and a VXLAN EVPN fabric, multi-pod designs included, with namespace normalisation across the boundary. The question stops being when do we cut over and becomes which tenant moves next. A Canadian estate with no maintenance appetite can stand the second fabric up beside the first and move at whatever pace the business tolerates.

Is it still worth investing in?.

Search interest across this family has fallen: the platform name by about a fifth in a year, the switch model numbers by half, the management product by nearly as much (source: DataForSEO, Canada, pulled 2026-09-03). That reflects fewer new builds, not fewer running fabrics. The estates are still there, still carrying production, and increasingly short of people who know the policy model. That's the work: keep it healthy, and design the thing it hands over to.
Spine-leaf fabric
THE METHOD

How our ACI migration and fabric design work runs.

Four steps, and step 01 is reading lifecycle notices rather than blog posts. We want your controller model, ACI release, switch models and management software version written down, then each checked against Cisco's published notices. Roughly half the anxiety we're called about turns out to be a hardware end-of-sale read as a product ending, and the other half a genuine software support date nobody diarised.

  1. Step 01

    Establish the real lifecycle position

    Controller hardware, ACI release, switch platforms and management software, each checked against the published notice that actually covers it, with dates. You get a written position per serial, not a rumour.

  2. Step 02

    Health and policy audit

    Fabric health, contract and policy sprawl, tenants that no longer exist, and the undocumented rules that will decide how hard any migration turns out to be.

  3. Step 03

    Stand the successor up beside it

    A standards-based fabric built alongside and interconnected to the existing one, so nothing is stranded and no date is forced on you by a vendor's calendar.

  4. Step 04

    Move tenants, then decommission

    Workload by workload with both fabrics live and a way back until each move passes its tests. The old fabric is retired only once it's empty.

QUESTIONS

Cisco ACI questions, answered straight.

Answers first, including whether the platform is being discontinued and what the lifecycle notices actually say. An architect takes the call, not a salesperson.

Cisco has published no end-of-life for the platform. Three things have been published and they get conflated: support for the older data centre management software ended in April 2026, its replacement runs on Nexus Dashboard and receives new switch image support exclusively, and certain controller appliances carry their own end-of-sale notice. That last one is a hardware refresh. Anyone telling you the platform is dead is reading a hardware notice, and anyone saying nothing changed missed a support date.

For new builds, less than it was. Canadian search interest in the platform is down about a fifth year over year and the switch model numbers by half, which tracks fewer greenfield deployments. For running estates it's the opposite problem: the fabrics are still in production and the people who understood the policy model have moved on. Most of what we're asked for is keeping one healthy and planning what replaces it.

It's supported by the interconnect rather than excluded from it. The standards-based interconnect between an ACI fabric and a VXLAN EVPN fabric covers multi-pod as well as single-pod designs, with names normalised across the boundary so tenants keep their identity as they cross. Multi-site is a different design with its own considerations, and we'd want to see your setup before promising which pattern applies to you.

Probably, eventually, and not as an emergency. The reason isn't that the current platform stopped working, it's that the standards-based fabric is where the new features and the wider hiring pool are. Because the two interconnect, you can build the second fabric, prove it, and move tenants across a year or more. If somebody is quoting you a weekend cutover for a multi-pod estate, get a second opinion.

Three things, and only one of them is a phone number. Contract and lifecycle: what you pay per serial, and which published notice covers each controller, switch and software version. Escalation: an engineer who reads your policy model instead of asking you to upload the config again. Advisories and patching: version tracking, and the inventory an emergency directive will demand on short notice.

When the fabric is healthy, in support, and your team can operate it, because a migration with no forcing function is a large cost for a tidier diagram. When a hardware refresh is a year out, since the decision is much cheaper made once. And when nobody has read the lifecycle notices yet, as most of the urgency we meet dissolves once somebody does.

LET'S CONNECT

A senior engineer replies within an hour, 24/7.