Meraki or Catalyst: the question has moved

The question comes up in almost every first conversation: Meraki or Catalyst? It is usually asked as though it were about two product lines you pick between like two cars. In fact it is about the management path — and that is now the decision with the harder consequences.

Three paths, not two

• Meraki hardware in the Meraki dashboard. MX, MS and MR, cloud-managed from the start. The path with the lowest operational overhead and the clearest boundary: what the dashboard cannot do, you do not do.
• Catalyst with IOS XE, managed classically. Through the CLI, through automation or through Catalyst Center. The full depth of the platform, and the full operational overhead — with the freedom to use every feature IOS XE ships.
• Catalyst hardware in the Meraki dashboard. Cloud management with IOS XE: the same Catalyst 9000 switches, managed from the Meraki dashboard. The path that joins the two worlds — and the one where the details matter.

What ended on 31 March 2026

Between the two worlds there was a comfortable intermediate step for a long time: cloud monitoring for Catalyst. Catalyst switches appeared in the Meraki dashboard, largely read-only — statistics, configuration details, troubleshooting — without handing over management. That intermediate step is history.

The end was announced twice: 31 January 2026 was the original date, extended by two months. Anyone who read the extension as a sign that more would follow is now facing the migration without an intermediate step.

What migrating into Meraki management mode actually means

Moving Catalyst hardware into Meraki management mode is not a toggle. Meraki describes it without softening: during the migration the switch performs a factory reset. That reset erases the device's configuration and reformats the file systems — on the device and on any connected USB drives.

The way back exists but is not an undo: to migrate Cisco Catalyst 9000 switches from Meraki management back to DNA/CLI management, Meraki points to a support case and requires a DNA licence purchase order — and that path too resets the switch to factory defaults and erases all configurations. The documentation's explicit advice is to save a copy of your files beforehand.

When each one fits

None of this yields a recommendation for a brand. It yields one for a way of operating. The question is not which hardware is better — both are Cisco, both are mature. The question is which kind of operations you can actually run, and want to.

1. 01

   Many sites, little IT staff

   Meraki hardware in the dashboard. The standard carries itself through templates, operations need no CLI competence per site, and the platform's ceiling is rarely the ceiling of the requirement.

2. 02

   Deep campus requirements, your own network team

   Catalyst, classically managed. Where routing depth, special protocols or existing automation matter, giving up the command line is a real loss and not a convenience gain.

3. 03

   Catalyst in place, one interface wanted

   Cloud management with IOS XE — but as a planned migration with a backup, not as an experiment. The factory reset makes it a change with a maintenance window.

4. 04

   Mixed, and staying that way

   The most common reality: headquarters classical, branches cloud-managed. That is not a transitional state but a legitimate architecture — as long as the seam between the two is designed deliberately.

The question that comes before the brand question

Before Meraki or Catalyst is decided, another question deserves an answer: who operates this network in three years, and with which skills? A dashboard nobody runs with discipline produces the same sprawl as a CLI nobody masters. The platform does not decide the quality of operations — it only decides which kind of discipline they demand.

How we plan and run both paths is described under Cisco Meraki and enterprise networks. What the licensing side contributes is covered in the piece on Meraki licensing models; the structure of a multi-site rollout in the piece on the Meraki rollout.