Catalyst Center 2.3.7: maintenance ends in December, and the road to 3.x runs one way

A running Catalyst Center installation does not announce its end of support. The date sits in a Cisco table, and this time the answer is more than a patch: 3.x changes the architecture, touches the hardware question and brings features that can send data to Cisco cloud services.

What 17 December means

Cisco's guideline for Catalyst Center releases sets two end dates. After the end of software maintenance, a release gets no more maintenance releases or bug fixes and is no longer developed, repaired or tested. After the last date of support, all support services for it are unavailable. As a rule, the first date falls twelve months after release, the second 24 months.

The table goes back to 2.1.2.x; every release before 2.3.7 is past its last date of support too. What counts is the date in the table, not a period you work out yourself. For 3.x it has no entries yet (as of 16 March 2026), so settle the end of maintenance for your target release with Cisco or your partner before choosing it.

The road to 3.x runs one way

Cisco's upgrade guide records three things about the step from 2.3.7.x to 3.1.6: 3.1.6 is based on a new architecture, getting there requires the platform upgrade workflow, and afterwards you cannot switch back to an earlier release.

The guide also lists the permitted starting points: specific builds from the 2.3.7.7, 2.3.7.9, 2.3.7.10 and 2.3.7.11 patch lines. Anyone on another level patches within 2.3.7 first — and checks the build number against the list, not just the version.

So the target is not automatically the newest release. According to Cisco, the 3.x releases stand at different points:

• 3.1.6 is the target of the step from 2.3.7.x in the upgrade guide.
• 3.2.3 is generally available per its release notes, currently as maintenance update 3.2.3-75346.100.
• 3.3.1 is a controlled availability release per its release notes; access is by request through Cisco sales.

For 3.2.3 or 3.3.1, both release notes refer to Cisco's upgrade guide; we plan every intermediate step against it.

Hardware or virtual: the appliance has a say

The second decision concerns the platform underneath. The three appliance generations have dates years apart.

For 3.2.3 and 3.3.1, the software does not force a hardware swap. The hardware clocks run regardless: per the notice, DN2 service contracts can only be renewed until 25 June 2028. Cisco announced the end of life of DN3 on 2 July 2026, with a last ship date of 31 March 2027, and names DN4-HW-APL, DN4-HW-APL-L and DN4-HW-APL-XL as migration products. Per the DN4 data sheet, these require Catalyst Center 3.3.1 or newer — which Cisco currently offers only as controlled availability.

The third option is the virtual appliance, where the documentation differs by release:

• 3.1.6: per the data sheet VMware ESXi (vSphere 7.0.x or later), AWS and Microsoft Azure; for ESXi it lists 32 vCPUs, 256 GB RAM, 3 TB storage and 180 MB/s I/O bandwidth.
• 3.2.3: per the release notes only VMware ESXi and Ubuntu KVM, both on-premises.
• 3.3.1: per the release notes VMware ESXi on-premises and KVM (Ubuntu Native).

If you run in AWS or Azure, or plan to, check first that your target release is supported there. Moving from an appliance to a virtual instance is not an upgrade but a new platform design.

What 3.x brings, according to Cisco

Whether an upgrade is more than a met deadline depends on the features you use. The 3.1.6 data sheet and the 3.3.1 release notes name, among others:

• AI-driven baselining: a baseline of your network's performance parameters that adapts continuously and enables the AI analytics.
• AI-driven anomaly detection: detect performance issues, ignore harmless anomalies, reduce noise.
• ThousandEyes agents: deployed to all supported switches directly from Catalyst Center, for visibility into application performance.
• SWIM: central management of images, patches and maintenance updates; validated images as the standard per device family, role or tag — usually called the golden image.
• Plug and Play: off-the-shelf Cisco devices are provisioned simply by connecting them to the network (zero-touch deployment).
• Live Protect: new in 3.3.1 per the release notes; validates security shields that protect Cisco products without reloads or service interruptions.

The data sheet does not separate new from existing features; what is new for you only shows against what runs today. We recommend measuring each feature against an operational question: which current problem does it solve, and does it need licences, a cloud connection or a release you lack? Live Protect only arrives with 3.3.1.

How we bring Assurance into operations is covered under Assurance and troubleshooting; which IOS XE release makes a sound standard image, in the piece on IOS XE release strategy.

The AI Assistant: assess first, then switch on

The 3.1.6 data sheet presents the Cisco AI Assistant as a way to ask questions, analyse issues and take action across the network. Two points in Cisco's description of it matter before switching it on.

First, it requires registration with Cisco Catalyst Cloud, in the system settings under External Services, with a cisco.com account. Second, according to Cisco, customer content and customer systems information associated with the use of Catalyst Center are “primarily processed and stored in the United States, regardless of your physical location” — both the prompts and the deployment data the assistant analyses.

Per Cisco, this data is not used for training. The assistant is available for all licence tiers, but its functions follow the tiers of the features it uses.

The upgrade plan: maintenance tasks before, during and after the move

These points add up to a sequence that also answers which maintenance tasks a move to Catalyst Center 3.x involves.

1. 01

   Take stock

   Release and build number, appliance or virtual platform, single node or three-node cluster, features in use, integrations and API consumers — read from the platform, not the project documents.

2. 02

   Define the target

   Decide target release, platform and cloud features together, justified against the guideline and end-of-life dates.

3. 03

   Reach a valid starting point

   If the installation is not on a listed build, patch within 2.3.7 first — as a change with its own acceptance.

4. 04

   Back up and precheck

   A complete backup with a tested restore; work through the upgrade guide's prerequisites and procedure for exactly this path. The backup protects data; Cisco provides no way back to 2.3.7.

5. 05

   Test

   Rehearse the path where a failure costs nothing, and practise the acceptance checks at the same time.

6. 06

   Window and acceptance

   With a buffer, a go/no-go decision before the start and reachable owners for ISE, ITSM and automation. Accept operations, not the version string.

• Assurance: health data for known devices and clients is current; a known fault shows up as expected.
• Provisioning: a test device runs through Plug and Play to its approved configuration.
• SWIM: an image distribution to a pilot device completes; standard images are still set.
• Integrations: ISE, ITSM tickets and event subscriptions work; scripts and pipelines run against the new release.

The piece on the Catalyst Center API covers which interfaces typically hang off the platform. Three tasks stay: maintaining patch levels, tracking software and appliance dates, and planning the next move before maintenance ends.

How we plan platform upgrades and software levels is described under SWIM and lifecycle; a move to new hardware or a virtual instance belongs under deployment and platform design. If you need a sound decision before 17 December, discuss your Catalyst Center upgrade with us.