Control-M-Alternative: Worauf es bei der Ablösung wirklich ankommt

1. Der Bestand ist das Projekt – nicht das neue Tool

Ein gewachsenes Control-M hat Tausende Jobdefinitionen, Ordnerstrukturen, Kalender, Conditions, Variablen, Quantitative Resources und Reaktionen (Shouts, On-Do-Actions). Ein großer Teil davon ist historisch: Jobs, die seit Monaten nicht laufen, Kalender ohne Verwendung, Conditions, die niemand mehr erklären kann.

Worauf es ankommt:

• Vollständiger Export und ehrliche Abdeckungsanalyse. Bevor Sie irgendetwas migrieren, sollten Sie wissen, welche Objekttypen und Funktionen Ihr Bestand tatsächlich nutzt – und welche davon das Zielsystem abbildet. Ein Dry-Run mit Coverage-Report pro Objekt („angelegt / erkannt / übersprungen / Lücke“) ist dafür die Mindestanforderung. Alles andere ist Schätzen.
• Nicht nachbauen, sondern übernehmen. Jede manuelle Neuanlage ist eine Fehlerquelle und eine Abnahme mehr. Der Import muss Jobs, Ordner, Abhängigkeiten, Kalender, Ereignisse und Variablen maschinell übernehmen, reproduzierbar und beliebig oft wiederholbar.
• Bereinigen, aber getrennt vom Umzug. Aufräumen ist sinnvoll – aber als eigener Schritt mit eigener Abnahme. Wer Bereinigung und Migration vermischt, kann hinterher nicht mehr sagen, ob ein Job fehlt, weil er gestrichen wurde oder weil der Import ihn verloren hat.

2. Parallelbetrieb statt Stichtag

Ein Big-Bang-Wechsel über ein Wochenende klingt effizient und ist in der Praxis der Hauptgrund für abgebrochene Projekte. Produktive Nachtketten lassen sich nicht in einer Testumgebung vollständig nachstellen – zu viele Abhängigkeiten zu Fachanwendungen, Dateieingängen und Fremdsystemen.

Worauf es ankommt:

• Server für Server, Bereich für Bereich. Das Zielsystem muss neben Control-M laufen können, ohne dass die bestehende Installation angefasst wird. Ein Server (oder Fachbereich) wird umgestellt, läuft zwei Wochen produktiv, wird abgenommen – dann der nächste.
• Diff statt Vertrauen. Nach jedem Import muss nachvollziehbar sein, was sich gegenüber dem letzten Stand geändert hat. Control-M wird während der Migration weiter gepflegt; Änderungen dürfen nicht verloren gehen.
• Ein klares Abnahmekriterium. Zum Beispiel: zehn Werktage produktiv ohne Störung der Prioritätsstufe 1. Das ist messbar und für Fachbereich, Betrieb und Einkauf gleich verständlich.

3. Das Betriebswissen steckt in Köpfen, nicht in Dokumenten

Welche Kette darf nach einem Fehler einfach neu gestartet werden, welche nicht? Warum hängt der Export jede Nacht an derselben Condition? Dieses Wissen ist bei zwei, drei Personen – und die sind im Projekt ohnehin ausgelastet.

Worauf es ankommt:

• Das Zielsystem muss Zusammenhänge selbst erklären können. Abhängigkeiten über Ordnergrenzen hinweg, Vorgänger und Nachfolger, Laufsperren, der Grund für einen wartenden Job – das muss in der Oberfläche sichtbar sein, nicht nur im Kopf des Control-M-Spezialisten. Ein Assistent, der auf die Frage „Warum warten diese Jobs?“ die Kette bis zum Ursprung durchgeht, spart im Betrieb mehr Zeit als jede zusätzliche Funktion.
• Bedienbar ohne Spezialausbildung. Der Markt für Control-M-Erfahrung ist eng und teuer. Wenn das neue System nur von denselben Spezialisten bedient werden kann, haben Sie eine Abhängigkeit durch eine andere ersetzt.

4. SLA-Überwachung gehört von Anfang an dazu

In vielen Control-M-Installationen ist die Vorhersage von Fristüberschreitungen (BIM/Forecast) ein eigenes, separat lizenziertes Modul – und deshalb oft gar nicht im Einsatz. Die Folge: „Job rot“ ist die erste Nachricht, die der Fachbereich bekommt, und sie kommt zu spät.

Worauf es ankommt: Zielzeiten für kritische Ketten, eine laufende Prognose („im Plan / gefährdet / verletzt“) mit Begründung, und Alarme, die ausgelöst werden, solange noch Zeit zum Eingreifen ist. Das muss im Standard enthalten sein, nicht als Zusatzbaustein.

5. Revisionssicherheit ist kein Komfortmerkmal

Wer in regulierten Branchen oder mit Jahresabschluss-Ketten arbeitet, braucht bei jeder Änderung die Antwort auf: wer, wann, was, vorher/nachher. Bei der Ablösung ist das doppelt relevant – die Migration selbst ist eine Änderung an Tausenden Objekten.

Worauf es ankommt: lückenloses Audit-Log inklusive Löschungen, Snapshots mit Wiederherstellung, Vier-Augen-Freigabe für kritische Änderungen. Und: KI-gestützte Vorschläge dürfen nie selbst speichern oder starten – ein Mensch bestätigt, mit Audit-Eintrag.

6. Lizenzmodell und Ausstieg rechtzeitig klären

Control-M wird typischerweise pro Endpoint/Agent abgerechnet, Zusatzmodule (Managed File Transfer, Forecast, Archivierung) kommen obendrauf. Verlängerungen laufen oft über drei Jahre – wer erst sechs Monate vor dem Renewal anfängt, verhandelt unter Druck.

Worauf es ankommt:

• Zeitplan rückwärts vom Renewal. Ablösung inklusive Parallelbetrieb braucht realistisch 9–18 Monate, je nach Größe. Der Zeitpunkt für die Entscheidung ist also deutlich früher, als die meisten denken.
• Kein neuer Lock-in. Prüfen Sie beim Zielsystem: Lizenzierung pro Agent/Endpoint oder pro Umgebung? Sind Dateitransfer, Prognose, Mandanten und Testumgebungen enthalten? Lässt sich der Bestand wieder exportieren? Gibt es Quellcode-Escrow für den Fall, dass der Hersteller ausfällt?
• Lizenz- und Dienstleistungsvertrag trennen. Sonst hängt der Betrieb des Schedulers an einem Beratungsbudget.

Checkliste für die Entscheidung

Wie Conductral das umsetzt

Conductral wurde genau für diesen Weg gebaut: Control-M-Exporte (Automation-API-JSON, ZIP, XML) werden eingelesen, der Dry-Run zeigt die Abdeckung pro Objekt, die Übernahme erfolgt in einer Transaktion, der Parallelbetrieb Server für Server. SLA-Prognose, Dateitransfer, Mandanten und der Assistent Maestro sind im Standard enthalten; die Lizenz gilt pro Produktivumgebung, nicht pro Agent. Details: Control-M-Alternative · Vergleich mit Control-M, Automic und Airflow

Wenn Sie wissen wollen, wie Ihr eigener Bestand abgedeckt wäre: Schicken Sie uns einen Export, wir zeigen Ihnen den Coverage-Report in einer Demo. Demo anfragen

Control-M ist eine Marke von BMC Software, Inc.