Meraki oder Catalyst: Die Frage hat sich verschoben

Die Frage kommt in fast jedem Erstgespräch: Meraki oder Catalyst? Sie wird meist gestellt, als ginge es um zwei Produktlinien, zwischen denen man sich wie zwischen zwei Autos entscheidet. Tatsächlich geht es um den Verwaltungsweg — und der ist inzwischen die Entscheidung mit den härteren Folgen.

Drei Wege, nicht zwei

• Meraki-Hardware im Meraki-Dashboard. MX, MS und MR, cloud-verwaltet von Anfang an. Der Weg mit dem geringsten Betriebsaufwand und der klarsten Grenze: Was das Dashboard nicht kann, geht nicht.
• Catalyst mit IOS XE, klassisch verwaltet. Über CLI, über Automatisierung oder über Catalyst Center. Die volle Tiefe der Plattform, dafür der volle Betriebsaufwand — und die Freiheit, jede Funktion zu nutzen, die IOS XE mitbringt.
• Catalyst-Hardware im Meraki-Dashboard. Cloud Management mit IOS XE: dieselben Catalyst-9000-Switches, verwaltet über das Meraki-Dashboard. Der Weg, der die beiden Welten verbindet — und der Weg, bei dem die Details zählen.

Was zum 31. März 2026 endete

Zwischen den Welten gab es lange einen bequemen Zwischenschritt: Cloud Monitoring für Catalyst. Catalyst-Switches erschienen im Meraki-Dashboard, weitgehend lesend — Statistiken, Konfigurationsdetails, Fehlersuche —, ohne die Verwaltung abzugeben. Dieser Zwischenschritt ist Geschichte.

Das Ende war zweimal angekündigt: Ursprünglich stand der 31. Januar 2026 im Raum, das Datum wurde um zwei Monate verlängert. Wer die Verlängerung als Signal gelesen hat, dass es noch weitere geben würde, steht jetzt vor der Migration ohne Zwischenstufe.

Was eine Migration in den Meraki-Modus tatsächlich bedeutet

Eine Catalyst-Hardware in den Meraki-Verwaltungsmodus zu überführen, ist kein Umschalten. Meraki beschreibt es ohne Beschönigung: Während der Migration führt der Switch einen Werksreset durch. Der Reset löscht die Konfiguration des Geräts und formatiert die Dateisysteme neu — auf dem Gerät und auf jedem angeschlossenen USB-Laufwerk.

Der Rückweg existiert, ist aber kein Rückgängigmachen: Für die Migration von Cisco-Catalyst-9000-Switches aus der Meraki-Verwaltung zurück in die DNA-/CLI-Verwaltung verweist Meraki auf den Support, verlangt eine DNA-Lizenzbestellung — und auch dieser Weg setzt den Switch auf Werkseinstellungen zurück und löscht alle Konfigurationen. Der ausdrückliche Hinweis der Dokumentation lautet, vorher eine Kopie der Dateien zu sichern.

Wann was passt

Aus alldem folgt keine Empfehlung für eine Marke, sondern eine für eine Betriebsform. Die Frage ist nicht, welche Hardware besser ist — beide sind Cisco, beide sind ausgereift. Die Frage ist, welchen Betrieb Sie tatsächlich führen können und wollen.

1. 01

   Viele Standorte, wenig IT-Personal

   Meraki-Hardware im Dashboard. Der Standard trägt sich über Templates, der Betrieb braucht keine CLI-Kompetenz je Standort, und die Grenze der Plattform ist selten die Grenze des Bedarfs.

2. 02

   Tiefe Campus-Anforderungen, eigenes Netzteam

   Catalyst klassisch. Wo Routing-Tiefe, Sonderprotokolle oder bestehende Automatisierung zählen, ist der Verzicht auf die Kommandozeile ein echter Verlust und kein Komfortgewinn.

3. 03

   Catalyst im Bestand, Wunsch nach einer Oberfläche

   Cloud Management mit IOS XE — aber als geplante Migration mit Bestandssicherung, nicht als Versuch. Der Werksreset macht daraus einen Change mit Wartungsfenster.

4. 04

   Gemischt, und das bleibt so

   Die häufigste Realität: Zentrale klassisch, Filialen cloud-verwaltet. Das ist keine Übergangslösung, sondern eine legitime Architektur — solange die Naht zwischen beiden bewusst entworfen ist.

Die Frage, die vor der Markenfrage steht

Bevor Meraki oder Catalyst entschieden wird, gehört eine andere Frage beantwortet: Wer betreibt das Netz in drei Jahren, und mit welchen Fähigkeiten? Ein Dashboard, das niemand diszipliniert führt, erzeugt genauso Wildwuchs wie eine CLI, die niemand beherrscht. Die Plattform entscheidet nicht über die Qualität des Betriebs — sie entscheidet nur, welche Art von Disziplin er verlangt.

Wie wir beide Wege planen und betreiben, steht unter Cisco Meraki und Enterprise Networks. Was die Lizenzseite dazu beiträgt, behandelt der Beitrag zu den Meraki-Lizenzmodellen; die Struktur eines Rollouts über viele Standorte der Beitrag zum Meraki-Rollout.