Cloud-Managed Catalyst, Explained: Management Mode vs Configuration Source

Engineer's guide to what Cisco actually asks you when you onboard a Catalyst or Smart Switch to the Meraki dashboard, and what each choice does to your config, your CLI, and your firmware floor. 

The short version

Cisco now lets you run Catalyst 9000 switches from the Meraki dashboard, but the onboarding workflow asks two separate questions that are easy to confuse: management mode and configuration source. Management mode decides who runs the switch, the Meraki cloud or your on-premises tools. Configuration source decides where the running configuration lives, fully in the cloud or locally on the device. They are independent choices, and the combination you pick determines three things that matter operationally: whether your existing CLI configuration survives onboarding, whether you keep write access to the CLI, and which IOS XE version you need. This guide lays out the whole picture.

Two questions, kept separate

Management mode: cloud or on-premises

Management mode is the first decision. Cloud management means the device is run through the Meraki dashboard. On-premises management means you onboard the switch to an on-prem network in the dashboard for inventory and license visibility, then keep managing it the way you do today, through your existing on-prem platform or the CLI. On-prem mode is the lightest touch: you get the device into your dashboard inventory without changing how it is operated.

Configuration source: cloud or device

Configuration source only comes into play once you have chosen cloud management, and it is where most of the confusion lives. Configuration source: cloud means the Meraki cloud is the authoritative source for the running config. You configure in the dashboard, the config is stored in the cloud and synced down to the switch, and the local configuration is replaced during onboarding. Configuration source: device means the configuration stays on the device with a cloud backup. You keep configuring locally (console, SSH, or the in-dashboard Cloud CLI), and the dashboard is there for monitoring, troubleshooting, and visibility.

Said plainly: cloud configuration hands the keys to the dashboard. Device configuration keeps the keys on the switch and uses the dashboard as a window into it.

The three outcomes you can actually land on

1. Cloud management, configuration source: cloud (formerly just "Cloud Management"). The full cloud experience. The dashboard owns the config. Best when you are standardizing on Meraki dashboard operations or deploying greenfield and want the simplest model.
2. Cloud management, configuration source: device (formerly "Cloud Monitoring"). Cloud visibility and a read/write Cloud CLI, with the config still living on the switch. Best when you want dashboard monitoring and troubleshooting without giving up CLI-driven configuration, or as a low-risk first step before committing to full cloud config.
3. On-premises management. Inventory and licenses in the dashboard, device run as usual. Best when all you want is dashboard-level asset and license visibility.

Cloud configuration vs device configuration, side by side

What about Catalyst Center? Expanding the on-premises option

The third outcome above, on-premises management, deserves more than one line, because it is where Catalyst Center lives and because the management-mode and configuration-source choices in the Meraki onboarding do not apply to it.

Catalyst Center (formerly DNA Center) is a separate, on-premises management platform. It automates, provisions, and monitors switches running standard IOS XE, and it leaves the running configuration on the switch while keeping full read and write CLI and SSH access. It never converts the switch into a cloud operating mode and never makes the console read-only. In the two-axis framing, Catalyst Center is an on-premises management choice, and the cloud-versus-device configuration-source decision is a Meraki concept with no Catalyst Center equivalent.

There is a licensing catch, and it is the one that matters. Catalyst Center keeps your CLI, but it is gated behind a DNA or Catalyst Center subscription. Full local management and a recurring subscription come bundled together.

Put the options side by side and the pattern is clear. There are four ways to run a Catalyst switch, and only one keeps full local CLI with no recurring subscription:

The only path with full local CLI and no recurring subscription is standalone management on a switch carrying a perpetual Network Essentials or Network Advantage license.

One note for completeness: Cisco is converging the two panes. Global Overview, which reached general availability around the end of 2025, gives a unified view across Catalyst Center and Meraki devices from one dashboard with single sign-on. Underneath, the two remain distinct management paradigms, so the four paths above still hold. For a deeper comparison of the platforms, see Cisco Catalyst Center vs the Meraki Dashboard.

Where this came from: container (CS) to IOS XE

Earlier cloud-managed Catalyst switches ran a container-based firmware Cisco refers to as the CS trains (CS15, CS16, CS17). Starting with IOS XE 17.15, Cisco began moving to a container-less architecture branded Cloud Management with IOS XE. That is the dividing line you will see in a lot of the documentation: "CS firmware" is the old container model, "Cloud Management with IOS XE" is the new one.

Two consequences are worth committing to memory:

• Downgrades are restricted. Once a switch moves from CS to Cloud Management with IOS XE, downgrading back to CS firmware through the dashboard is restricted. It can require a factory reset and Meraki support, and getting a support team assigned can take up to a day. Treat the move to IOS XE cloud management as a one-way door for production gear and plan accordingly.
• CS switches should be on CS17 first. Cloud-managed Catalyst switches scheduled to upgrade from any CS version to Cloud Management with IOS XE (17.15+) should meet the CS17 minimum before upgrading.

Which switches support what

This is the consolidated, current support matrix. Cloud config and device config can have different minimum versions for the same family, which is exactly the kind of detail the older blog posts got wrong.

C9500 High Performance refers specifically to the C9500-48Y4C, C9500-24Y4C, C9500-32C, and C9500-32QC. Always confirm the exact SKU against Cisco's table before onboarding, since an unsupported model can be bricked.

Catalyst vs Smart Switch: different commands, different onboarding

This is the distinction that trips people up. The Catalyst 9300, 9200, and 9500 High Performance are migrated to the cloud with one command set. The newer C9000 Smart Switches (C9350, C9610, C9550) are a different generation with a different onboarding path.

• Catalyst 9200 / 9300 / 9500 High Performance: migrate with service meraki connect, verify with show meraki connect and show meraki compatibility. Onboarding produces a Meraki MAC and a Cloud ID via the CLI.
• C9000 Smart Switches (C9350 / C9610 / C9550): use service cloud-mgmt connect and show cloud-mgmt. These ship cloud-ready and onboard with a zero-touch provisioning flow. You claim the device by the Cloud ID printed on the sticker (front or top of the unit) or by order number, then assign it to a network. During zero-touch provisioning, do not press any keys on the console, since a keystroke interrupts ZTP and forces manual recovery.

If you read a migration guide that uses service meraki connect and then tells you it also covers the C9350, that guide is conflating two onboarding paths.

Gotchas worth knowing before you onboard

• Config erasure is a cloud-configuration behavior, not a universal one. Cloud configuration replaces the local config, formats flash and any attached USB storage, and makes the console read-only. Device configuration preserves your config and keeps CLI write access. If wiping a production switch sounds wrong, you probably want device configuration.
• Full-encryption image, install mode. Migration requires a full-encryption IOS XE image (No Payload Encryption images are not supported) and the switch in install mode, not bundle.
• Network modules gate the migration. An unsupported network module will fail the migration. Check the module against the current supported list and the per-module minimum firmware first.
• Licensing and the DNA entitlement window. Device configuration requires an active DNA Essentials or Advantage license (traffic and application analytics need Advantage). Separately, Cisco's Cloud Entitlement for DNA offer lets eligible devices migrate to cloud management on an existing DNA license with no additional license migration or transfer required until February 1, 2029.
• Cloud Monitoring is sunset. Cloud Monitoring for Catalyst has folded into device configuration. Existing Cloud Monitoring switches were to transition by March 31, 2026, and new switches now onboard directly into device configuration (17.15.3+) through the dashboard, with no separate onboarding application.

Frequently asked questions

What is the difference between management mode and configuration source? Management mode decides who runs the switch, the Meraki cloud or your on-prem tools. Configuration source decides where the config lives, fully in the cloud or on the device. They are independent.

What is the difference between cloud configuration and device configuration? Cloud configuration puts the dashboard in charge of the config and replaces the local config during onboarding, with a read-only Cloud CLI. Device configuration keeps the config on the switch with a cloud backup, keeps read and write CLI, and uses the dashboard for monitoring and troubleshooting.

Does onboarding to Meraki erase my configuration? Only in cloud configuration mode. Device configuration preserves it.

Can I downgrade from Cloud Management with IOS XE back to CS firmware? Through the dashboard, it is restricted. It can require a factory reset and Meraki support, with up to a day to get support assigned.

Do C9350 Smart Switches onboard like a Catalyst 9300? No. They use service cloud-mgmt connect and a zero-touch claim-by-Cloud-ID flow, not service meraki connect.

What happened to Cloud Monitoring? It became cloud management with device configuration. Transition was required by March 31, 2026.

How is Catalyst Center different from managing a switch in the Meraki dashboard? Catalyst Center is a separate on-premises management platform. It automates and monitors switches running standard IOS XE while leaving the configuration on the device and keeping full read and write CLI access, so it never makes the console read-only the way Meraki cloud configuration does. The Meraki configuration-source choice does not apply to it, and the tradeoff is that Catalyst Center requires a DNA or Catalyst Center subscription.