RMM wechseln: Migrations-Checkliste
Eine RMM-Migration ist überwiegend ein Rollout-Problem und kein Datenproblem, und sie geht auf vorhersehbare Weise schief: Agenten, die sich in die Quere kommen, Monitoring-Lücken, die eine Woche lang niemand bemerkt, und ein Abbauschritt, an den erst die Rechnung erinnert. Diese Checkliste ist herstellerneutral und funktioniert in beide Richtungen.
Veröffentlicht am 7. August 2026
Die eine Regel
Schalten Sie nie in einem Schritt um. Betreiben Sie beide Systeme für einen festgelegten Zeitraum parallel, prüfen Sie das neue gegen das alte und entfernen Sie erst danach den alten Agenten. Der Parallelbetrieb macht aus der Migration einen Prozess statt eines Ereignisses und kostet einen Monat doppelte Lizenzgebühren — deutlich weniger als ein übersehener Ausfall.
Die zweite Regel folgt aus der ersten: Legen Sie die Abnahmekriterien fest, bevor Sie beginnen. Schreiben Sie prüfbar auf, was „das neue System funktioniert“ bedeutet, sonst zieht sich der Parallelbetrieb endlos und Sie zahlen aus Nervosität statt aus Erkenntnis für zwei Systeme.
Die sechs Phasen
In dieser Reihenfolge. Beginnen Sie den Agent-Rollout nicht, bevor die Richtlinien stehen, sonst haben Sie einen überwachten Gerätepark, der Alarme erzeugt, die niemand konfiguriert hat.
- 1
Inventar und Export
Exportieren Sie alles aus dem alten System, solange Sie Zugriff haben: Geräteliste mit Kennungen, Kunden- und Standortstruktur, Monitoring-Schwellwerte, Skripte, geplante Jobs, Dokumentation und Zugangsdaten. Zuerst — der Zugriff auf einen Export wird schwieriger, sobald gekündigt ist.
- 2
Struktur nachbauen
Legen Sie Mandanten, Standorte und Gerätegruppen im neuen System an, bevor der erste Agent kommt. Eine falsche Hierarchie ist später teuer, weil Richtlinien, Rechte und Auswertungen daran hängen.
- 3
Monitoring-Richtlinien neu aufbauen
Übernehmen Sie Schwellwerte nicht mechanisch. Eine Migration ist die seltene Gelegenheit, die Alarme loszuwerden, die Ihr Team seit zwei Jahren ignoriert. Beginnen Sie mit dem, worauf Sie tatsächlich reagieren, und ergänzen Sie den Rest nur, wenn er fehlt.
- 4
Pilot-Rollout
Verteilen Sie den neuen Agenten auf eine kleine, repräsentative Gruppe — eine Maschine je Betriebssystem, je Kundentyp, je unbequemem Netz. Lassen Sie beide Agenten eine Woche nebeneinander laufen und vergleichen Sie, was jeder meldet.
- 5
Flächen-Rollout
Verteilen Sie über den Kanal, dem Sie ohnehin vertrauen: Das alte RMM ist meist das beste Verteilwerkzeug für den neuen Agenten, daneben GPO, Intune oder eine skriptgesteuerte Installation. Verfolgen Sie die Abdeckung als Zahl und gehen Sie Nachzügler gezielt an.
- 6
Umschalten und abbauen
Wenn Abdeckung und Alarmierung geprüft sind, hören Sie auf, im alten System zu arbeiten, entfernen Sie dann dessen Agenten und kündigen Sie erst danach. In dieser Reihenfolge — Agenten zu früh zu entfernen macht Sie blind, und zuerst zu kündigen kann Sie den Export kosten.
Die Fallstricke, die wirklich wehtun
Diese erzeugen Vorfälle statt bloßen Ärgers.
Zwei Agenten streiten ums Patchen
Wenn beide Systeme Updates freigeben und installieren, erhalten Maschinen widersprüchliche Anweisungen und starten zu ungünstigen Zeitpunkten neu. Im Parallelbetrieb besitzt genau ein System das Patchen — üblicherweise das alte bis zur Umschaltung.
Stille Monitoring-Lücken
Die Abdeckung wird leicht überschätzt. Maschinen, die beim Rollout offline waren oder bei denen die Installation still fehlschlug, erzeugen keine Alarme — was sich nicht von einer gesunden Maschine unterscheiden lässt. Gleichen Sie die neue Geräteliste nach Anzahl und Namen gegen die alte ab, nicht nach Gefühl.
Skripte und Erfahrungswissen verlieren
Über Jahre gewachsene Automatisierung ist selten anderswo dokumentiert als in der alten Konsole. Exportieren Sie Skripte und geplante Jobs früh und notieren Sie, wofür jedes gedacht ist, solange sich noch jemand erinnert.
Den Abbau vergessen
Zurückgelassene alte Agenten verbrauchen weiter Lizenzen, halten auf jedem Endgerät einen unnötigen Fernzugriffsweg offen und werden zu ungepatchter Software. Die Entfernung ist Teil der Migration, kein Nachgedanke.
Wie lange es realistisch dauert
Für einige hundert Geräte und ein kleines Team planen Sie vier bis sechs Wochen von Anfang bis Ende: etwa eine Woche für Export und Struktur, eine Woche für Richtlinien, eine Woche Pilot, ein bis zwei Wochen Flächen-Rollout und eine abschließende Woche Parallelprüfung vor der Umschaltung.
Die bestimmende Größe ist nicht die Gerätezahl, sondern die Zahl unterschiedlicher Umgebungen: Betriebssysteme, Netztopologien und Kunden mit eigenen Änderungsprozessen. Zweihundert gleichartige Bürorechner migrieren schneller als vierzig Maschinen bei acht Kunden mit verschiedenen Wartungsfenstern.
Legen Sie die Umschaltung nicht unmittelbar vor eine Zeit, in der niemand verfügbar ist. In der Woche danach zeigen sich die Lücken, und genau dann möchten Sie die Menschen im Haus haben, die den Rollout gemacht haben.
Bevor Sie sich auf eine neue Plattform festlegen
Prüfen Sie das im Test, denn jeder dieser Punkte ist mitten in der Migration schmerzhaft.
- Agenten installieren unbeaufsichtigt auf jedem Betriebssystem Ihres Bestands, auch auf den Ständen, über die man ungern spricht.
- Der neue Agent lässt sich über Ihre bestehenden Kanäle verteilen — Installer, GPO, Skript oder das ausscheidende RMM.
- Monitoring-Richtlinien lassen sich je Gruppe zuweisen statt je Gerät, sonst dauert der Neuaufbau deutlich länger als geplant.
- Ticket-Historie und Dokumentation lassen sich übernehmen — oder Sie haben bewusst entschieden, sie zurückzulassen und Lesezugriff auf das alte System zu behalten.
- Der Export aus der neuen Plattform funktioniert, damit diese Migration nicht die letzte ist, die Sie durchführen können.
- Ob die Testphase lang genug für einen vollständigen Patch-Zyklus ist — zwei Wochen Evaluierung zeigen selten das, was ein Monat echter Betrieb zeigt.