COBOL-Nachfolge: wer euren Bestand in fünf Jahren pflegt
Der Host läuft, er verdient Geld, und er wird noch lange gebraucht. Die Frage ist nicht, wann er abgeschaltet wird, sondern wer ihn in der Zwischenzeit versteht.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Auf eine Ablösung warten, die seit acht Jahren im Fahrplan steht
In vielen Häusern gibt es eine Entscheidung, die nie ausgesprochen, aber überall spürbar ist: Der Host wird abgelöst, deshalb lohnt es sich nicht mehr, in ihn zu investieren. Es wird niemand eingestellt, es wird nicht ausgebildet, es wird nichts dokumentiert. Der Effekt ist paradox, denn genau diese Haltung macht die Ablösung teurer. Wer ein System ersetzen will, muss zuerst verstehen, was es tut, und dieses Verständnis schwindet mit jedem Jahr, in dem niemand nachrückt.
Gleichzeitig ist die Ausgangslage besser, als das Bild vom aussterbenden Großrechner nahelegt. Die jährliche Mainframe-Erhebung von BMC hat 2025 unter mehr als tausend Befragten ergeben, dass 66 Prozent sich der Generation Z oder den Millennials zuordnen, nach 37 Prozent im Jahr 2018. 97 Prozent bewerten die Plattform positiv, so viele wie in keiner Erhebung davor, und 72 Prozent der Organisationen melden wachsende Kapazität. Die Leute sind also da. Was fehlt, ist meistens der Weg, auf dem sie in euer System hineinkommen.
Der teuerste Fehler ist deshalb weder die Ablösung noch der Weiterbetrieb, sondern das Aussetzen. Ein Haus, das weder ablöst noch Nachfolge aufbaut, verliert mit jeder Verrentung einen Teil seiner Handlungsfähigkeit. Irgendwann steht die Anwendung nicht still, aber sie lässt sich nicht mehr ändern, und jede Anforderung aus dem Fachbereich wird zu einem Projekt mit unbekanntem Ausgang. Von dort aus ist auch die Ablösung kein Projekt mehr, sondern eine Rekonstruktion.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer im Haus wofür zuständig ist
Nachfolge scheitert selten an einer falschen Entscheidung und häufig daran, dass gar keine getroffen wird. Die folgende Aufteilung ordnet die sechs wiederkehrenden Themen jeweils einer Stelle zu und benennt, woran es in der Praxis hakt.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Ob eine Hostanwendung weitergeführt oder abgelöst wird | Die Geschäftsleitung gemeinsam mit dem Fachbereich, mit einem Beschluss und einem Datum, nicht als stillschweigende Erwartung | Die IT-Leitung, indem sie den Beschluss in Budget für Personal, Ausbildung oder Ablöseprojekt übersetzt | Die Ablösung steht seit Jahren im Fahrplan, ohne dass sie je beauftragt wurde. Das Ergebnis ist ein System, in das niemand mehr investiert und das trotzdem läuft. |
| Die Nachbesetzung im Bestand | Die Personalabteilung gemeinsam mit der Teamleitung, mit einem Profil, das Bereitschaft zum Einarbeiten verlangt statt jahrelanger COBOL-Erfahrung | Die Teamleitung, indem sie eine benannte Person aus dem Bestand für die Einarbeitung freistellt und diese Zeit im Fahrplan verplant | Gesucht wird jemand mit zehn Jahren Erfahrung in genau dieser Umgebung. Diese Person gibt es auf dem Markt kaum, und die Stelle bleibt jahrelang unbesetzt. |
| Das Sichern von Fachwissen aus dem Bestand | Die Teamleitung, als feste Regel für jede Änderung, nicht als einmaliges Dokumentationsprojekt | Wer die Änderung macht, indem er die fachliche Begründung an derselben Stelle festhält wie den Code | Es wird ein Dokumentationsprojekt aufgesetzt, das nach zwei Monaten endet. Der Bestand ändert sich weiter, das Dokument nicht, und nach einem Jahr traut ihm niemand mehr. |
| Der Zugang zu Test- und Übungsumgebungen | Der Betrieb der Plattform, entlang derselben Regeln, die auch für andere Systeme gelten | Der Betrieb, mit eigenen Bibliotheken je Person, einem Testbestand an Daten und der Möglichkeit, Läufe selbst zu starten | Der Zugang wird aus Sicherheitsgründen so eng gefasst, dass niemand Neues etwas ausprobieren kann. Damit ist jede Ausbildung theoretisch und jede Einarbeitung doppelt so lang. |
| Änderungen am Bestand und ihre Prüfung | Die Teamleitung, mit einer schriftlichen Regel darüber, wer allein ändern darf und was ein zweites Augenpaar braucht | Das Team über einen festen Prüfschritt vor der Auslieferung, unabhängig davon, wie klein die Änderung aussieht | Die Regel gilt für die Neuen und nicht für die erfahrene Person, die seit zwanzig Jahren dabei ist. Genau deren Änderungen sind aber die, bei denen niemand mehr mitliest. |
| Der Einsatz von KI-Werkzeugen im Bestand | Die IT-Leitung gemeinsam mit dem Datenschutz und der Sicherheit, bevor das erste Werkzeug ausprobiert wird | Das Team, mit klaren Grenzen: Erklären und Zusammenfassen ohne Freigabe, Erzeugen von Code nur mit derselben Prüfung wie bei handgeschriebenem | Das Werkzeug wird als Ersatz für das fehlende Verständnis eingesetzt. Es kann Code übersetzen, aber es weiß nicht, welche der dreißig Sonderfälle noch gelten und welche längst tot sind. |
Ob eine Hostanwendung weitergeführt oder abgelöst wird
- Wer entscheidet
- Die Geschäftsleitung gemeinsam mit dem Fachbereich, mit einem Beschluss und einem Datum, nicht als stillschweigende Erwartung
- Wer setzt um
- Die IT-Leitung, indem sie den Beschluss in Budget für Personal, Ausbildung oder Ablöseprojekt übersetzt
- Stolperfalle
- Die Ablösung steht seit Jahren im Fahrplan, ohne dass sie je beauftragt wurde. Das Ergebnis ist ein System, in das niemand mehr investiert und das trotzdem läuft.
Die Nachbesetzung im Bestand
- Wer entscheidet
- Die Personalabteilung gemeinsam mit der Teamleitung, mit einem Profil, das Bereitschaft zum Einarbeiten verlangt statt jahrelanger COBOL-Erfahrung
- Wer setzt um
- Die Teamleitung, indem sie eine benannte Person aus dem Bestand für die Einarbeitung freistellt und diese Zeit im Fahrplan verplant
- Stolperfalle
- Gesucht wird jemand mit zehn Jahren Erfahrung in genau dieser Umgebung. Diese Person gibt es auf dem Markt kaum, und die Stelle bleibt jahrelang unbesetzt.
Das Sichern von Fachwissen aus dem Bestand
- Wer entscheidet
- Die Teamleitung, als feste Regel für jede Änderung, nicht als einmaliges Dokumentationsprojekt
- Wer setzt um
- Wer die Änderung macht, indem er die fachliche Begründung an derselben Stelle festhält wie den Code
- Stolperfalle
- Es wird ein Dokumentationsprojekt aufgesetzt, das nach zwei Monaten endet. Der Bestand ändert sich weiter, das Dokument nicht, und nach einem Jahr traut ihm niemand mehr.
Der Zugang zu Test- und Übungsumgebungen
- Wer entscheidet
- Der Betrieb der Plattform, entlang derselben Regeln, die auch für andere Systeme gelten
- Wer setzt um
- Der Betrieb, mit eigenen Bibliotheken je Person, einem Testbestand an Daten und der Möglichkeit, Läufe selbst zu starten
- Stolperfalle
- Der Zugang wird aus Sicherheitsgründen so eng gefasst, dass niemand Neues etwas ausprobieren kann. Damit ist jede Ausbildung theoretisch und jede Einarbeitung doppelt so lang.
Änderungen am Bestand und ihre Prüfung
- Wer entscheidet
- Die Teamleitung, mit einer schriftlichen Regel darüber, wer allein ändern darf und was ein zweites Augenpaar braucht
- Wer setzt um
- Das Team über einen festen Prüfschritt vor der Auslieferung, unabhängig davon, wie klein die Änderung aussieht
- Stolperfalle
- Die Regel gilt für die Neuen und nicht für die erfahrene Person, die seit zwanzig Jahren dabei ist. Genau deren Änderungen sind aber die, bei denen niemand mehr mitliest.
Der Einsatz von KI-Werkzeugen im Bestand
- Wer entscheidet
- Die IT-Leitung gemeinsam mit dem Datenschutz und der Sicherheit, bevor das erste Werkzeug ausprobiert wird
- Wer setzt um
- Das Team, mit klaren Grenzen: Erklären und Zusammenfassen ohne Freigabe, Erzeugen von Code nur mit derselben Prüfung wie bei handgeschriebenem
- Stolperfalle
- Das Werkzeug wird als Ersatz für das fehlende Verständnis eingesetzt. Es kann Code übersetzen, aber es weiß nicht, welche der dreißig Sonderfälle noch gelten und welche längst tot sind.
Fünf Fragen zur Lage eures Bestands
- 01 Wie viele Leute können heute eine Änderung an dieser Anwendung eigenständig machen?
- 02 Wann geht die erste dieser Personen in Rente, und wann die zweite?
- 03 Gibt es eine Umgebung, in der jemand Neues gefahrlos etwas ausprobieren kann?
- 04 Steht die Begründung für Sonderfälle irgendwo, oder nur in einem Kopf?
- 05 Was kostet ein Tag Stillstand dieser Anwendung im Fachbereich?
Was ihr aufbaut, solange die Überlappung noch möglich ist
Nachfolge im Bestand ist keine Personalfrage allein. Sechs Punkte machen den Unterschied zwischen einer geordneten Übergabe und einer Rekonstruktion aus dem Quelltext.
Die Überlappung als Zeitraum planen, nicht als Einarbeitungswoche
Wer in eine gewachsene Hostanwendung hineinwächst, braucht Monate an echter Arbeit mit jemandem daneben, der sie kennt. Das ist kein Zeichen mangelnder Begabung, sondern die Menge an Fachlichkeit, die dort steckt. Rechnet die Überlappung in Personenmonaten und legt sie so, dass sie vor und nicht nach dem Renteneintritt liegt.
Wissen an das Artefakt binden statt an die Person
Fragt bei jeder Änderung, die ansteht, nicht nur nach dem Code, sondern nach der Begründung. Warum steht dieser Sonderfall im Programm, welcher Vorgang im Fachbereich hat ihn ausgelöst, welche Regel gilt seit wann. Das gehört als Kommentar an die Stelle oder als Eintrag an das Modul, nicht in ein separates Dokument, das niemand aufmacht.
Eine Umgebung schaffen, in der Fehler folgenlos sind
Der häufigste Grund dafür, dass jemand Neues nicht vorankommt, ist fehlender Zugang. Ohne Testsystem, ohne eigene Bibliothek, ohne die Möglichkeit, einen Lauf zu starten und scheitern zu lassen, bleibt jedes Lernen theoretisch. Diese Umgebung einzurichten ist Arbeit für den Betrieb und der wirksamste einzelne Hebel überhaupt.
Den Einstieg in die Umgebung trennen vom Einstieg in die Sprache
COBOL selbst ist der leichtere Teil. Schwerer ist alles, was drumherum steht: die Steuerungssprache für Stapelverarbeitung, die Dateiorganisation, der Transaktionsmonitor, die Datenbank, die Werkzeuge zur Fehlersuche und die Regeln, nach denen bei euch ausgeliefert wird. Behandelt beides als getrennte Lernwege mit getrennten Zielen.
Nicht auf Zuruf aus dem Bestand herausmodernisieren
Wenn Schnittstellen nach außen gebraucht werden, ist das eine gute Investition, weil sie den Bestand nutzbar macht, ohne ihn anzufassen. Ein vollständiges Umschreiben ohne belastbares Verständnis der Fachlogik ist dagegen der Weg, auf dem Projekte scheitern. Beides sind sinnvolle Vorhaben, aber sie haben unterschiedliche Voraussetzungen.
Die Arbeit im Bestand sichtbar und attraktiv halten
Wer in einem Haus arbeitet, in dem der Host als Abstellgleis gilt, sucht sich anderswo eine Aufgabe. Sichtbarkeit hilft: Erzählt intern, welche Umsätze über diese Anwendung laufen, welche Aufgaben dort anstehen und welche Werkzeuge dabei zum Einsatz kommen. Das ist keine Kosmetik, sondern die Voraussetzung dafür, dass sich überhaupt jemand meldet.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was am Bild vom aussterbenden Großrechner nicht stimmt
Die Erzählung ist seit Jahrzehnten dieselbe: Der Host ist ein Auslaufmodell, die Leute gehen in Rente, danach ist Schluss. Die Zahlen aus der Praxis stützen das nicht. Die jährliche Mainframe-Erhebung von BMC hat 2025 unter mehr als tausend Fachleuten weltweit ergeben, dass 97 Prozent die Plattform positiv sehen, dass 72 Prozent der Organisationen wachsende Kapazität melden und dass sich 66 Prozent der Befragten der Generation Z oder den Millennials zuordnen. 2018 waren es 37 Prozent. Die Belegschaft wird also jünger und nicht älter.
Das Werkzeug entwickelt sich ebenfalls weiter. COBOL ist eine normierte Sprache, die dritte Ausgabe der Norm ISO/IEC 1989 stammt aus dem Jahr 2023. Auf der Plattform selbst erscheinen weiterhin neue Compilerversionen, IBM hat Enterprise COBOL for z/OS in der Fassung 6.5 im Jahr 2025 allgemein verfügbar gemacht. Wer sich mit dem Bestand beschäftigt, arbeitet also nicht in einem eingefrorenen Umfeld, sondern in einem gepflegten.
Was dagegen zutrifft, ist ein Übergabeproblem in einzelnen Häusern. Wenn dreißig Jahre lang niemand nachgerückt ist, dann fehlt der Nachwuchs eben dort, und daran ändert eine gute Marktlage nichts. Die Unterscheidung ist wichtig, weil sie die Aufgabe verändert: Ihr müsst keine untergehende Technologie retten, ihr müsst eine Übergabe organisieren, die zu lange aufgeschoben wurde.
Was das Wissen aus dem Bestand tatsächlich ausmacht
COBOL ist als Sprache eher einfach. Die Syntax ist wortreich und dadurch gut lesbar, es gibt keine versteckten Konstrukte, und wer schon einmal programmiert hat, kann nach wenigen Tagen ein Programm nachvollziehen. Wer den Bestand für schwierig hält, weil die Sprache alt ist, hat den Grund noch nicht gefunden. Der Grund ist die Umgebung und die Fachlichkeit.
Zur Umgebung gehören die Steuerungssprache für Stapelverarbeitung, die Organisation der Datenbestände, der Transaktionsmonitor für die Dialogverarbeitung, die Datenbank und die Werkzeuge zur Fehlersuche. Dazu kommen die Regeln des Hauses: Wie ein Nachtlauf aufgebaut ist, was passiert, wenn ein Schritt abbricht, in welcher Reihenfolge Bestände aufgebaut werden, welche Zeitfenster gelten. Das ist der Teil, für den es Kurse gibt und für den sich Kurse lohnen, weil er sich systematisch vermitteln lässt.
Der zweite Teil lässt sich nicht schulen. Wenn ein Programm an einer Stelle eine Bedingung prüft, die sonst nirgends vorkommt, dann steht dahinter ein Vorgang aus dem Fachbereich, meist aus einem bestimmten Jahr und mit einem bestimmten Anlass. Dieses Wissen liegt in wenigen Köpfen, und es ist der eigentliche Wert. Es lässt sich nur bergen, indem jemand daneben sitzt und fragt, und zwar solange die Person noch da ist, die die Antwort kennt.
Wie ein realistischer Einstieg aussieht
Der erste Monat gehört der Sprache und den Werkzeugen. Ein Grundkurs bringt jemanden dahin, ein Programm zu lesen, zu ändern, zu übersetzen und einen Lauf zu starten. Das ist bewusst wenig, aber es ist die Schwelle, ab der Lernen im echten Bestand überhaupt möglich wird. Wer diese Schwelle nicht überschreitet, kann bei einer Fehlersuche nur zusehen.
Danach beginnt die Arbeit an echten, kleinen Aufgaben, mit jemandem daneben. Gut geeignet sind Änderungen mit klarem Umfang und geringem Risiko: eine zusätzliche Prüfung, ein neues Feld in einer Ausgabe, eine Fehlermeldung, die nicht aussagekräftig genug ist. Jede solche Aufgabe bringt die neue Person mit einem Stück der Umgebung in Berührung, und das Gespräch dabei ist der eigentliche Wissenstransfer. Rechnet für diese Phase mit Monaten und nicht mit Wochen.
Für den Einstieg gibt es außerdem frei zugängliches Material, das den Kurs ergänzt. Das Open Mainframe Project stellt einen offenen COBOL-Kurs bereit, IBM betreibt mit Z Xplore eine Lernumgebung, auf der sich die Plattform ohne eigenes System ausprobieren lässt. Beides ersetzt keine Schulung an eurer Umgebung, aber es senkt die Hemmschwelle und es zeigt Interessierten, dass der Bereich lebt.
Ablösung und Weiterbetrieb sind keine Gegensätze
Ein Bestandssystem abzulösen ist eine legitime Entscheidung, und es gibt gute Gründe dafür. Was selten funktioniert, ist der Weg über ein vollständiges Umschreiben in einem Zug, weil die Anforderung dafür lautet: Bilde alles nach, was diese Anwendung tut, einschließlich der Sonderfälle, die niemand kennt. Diese Anforderung lässt sich nicht schreiben, solange das Wissen fehlt, und deshalb hängt auch die Ablösung an derselben Nachfolgefrage wie der Weiterbetrieb.
Der Weg, der in der Praxis öfter trägt, geht über Schnittstellen. Der Bestand bekommt eine saubere Fassade nach außen, über die neue Anwendungen ihn ansprechen können, ohne seine Interna zu kennen. Danach lassen sich einzelne Aufgaben schrittweise herauslösen und außerhalb neu bauen, während der Rest weiterläuft. Jeder Schritt ist für sich prüfbar, und das Vorhaben lässt sich anhalten, ohne einen halbfertigen Zustand zu hinterlassen.
KI-Werkzeuge gehören inzwischen in dieses Bild, aber an einer klar begrenzten Stelle. Es gibt Angebote, die COBOL-Code erklären, zusammenfassen und in andere Sprachen überführen, etwa auf Basis der Werkzeuge, die IBM für die Plattform anbietet. Beim Verstehen eines fremden Programms ist das eine echte Hilfe. Beim Erzeugen von Ersatzcode bleibt die Verantwortung dieselbe: Jemand muss beurteilen, ob das Ergebnis fachlich stimmt, und diese Beurteilung setzt genau das Wissen voraus, dessen Fehlen das eigentliche Problem ist.
Dazu passende Kurse
Wenn jemand aus dem Team an die Hostanwendungen heranwachsen soll, sind COBOL-Schulungen für den Einstieg in den Bestand der schnellste Weg über die erste Schwelle.
Kommt jemand aus einer anderen Sprache in euer Team, findest du bei cmt Programmierkurse für den Wechsel in ein neues Umfeld .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr umfangreicher Überblick über Zusammenhänge und Anwendungsbereiche. Sehr zu empfehlen.
Effektives, gemeinsames Erarbeiten der Aufgaben mit vielen praktischen Tipps.
Sehr guter Trainer und gute Aufbereitung der Inhalte und auch eingehen auf Fragen der Beteiligten.
Häufige Fragen
Wie lange braucht jemand, um im COBOL-Bestand produktiv zu werden?
Finden wir überhaupt noch Leute für den Bestand?
Sollen wir überhaupt noch in COBOL investieren, wenn wir ablösen wollen?
Können KI-Werkzeuge unseren COBOL-Code einfach in Java übersetzen?
Was ist das erste, was wir tun sollten?
Passt thematisch dazu
Diese Seite beschreibt das Vorgehen im Haus, das den Bestand hält, und wer die Stelle besetzen will, sollte zusätzlich wissen, wie der Einstieg in den Bestand aus Sicht der Bewerber aussieht .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Programmierung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Nachwuchs an den Bestand heranführen
Bei cmt bringen die COBOL-Kurse jemanden ohne Vorerfahrung dahin, Programme zu lesen, zu ändern und Läufe zu starten. Ab da kann die Einarbeitung an eurer eigenen Anwendung beginnen.
Passt dazu
- Clean Core in S/4HANA: was aus euren ABAP-Erweiterungen wird
- Von Java 8 wegkommen: was der Sprung auf eine aktuelle LTS wirklich verlangt
- Anforderungen so aufschreiben, dass Entwicklung und Test dasselbe verstehen
- Code Reviews einführen, ohne dass sie zum Nadelöhr werden