Was sind die vier Strategien zur Mainframe-Modernisierung?

Rehost, Replatform, Refactor und Retain. Ein Rehost verschiebt den Workload auf einen Emulator oder eine Cloud-Instanz, ohne den Code zu ändern. Ein Replatform tauscht die Laufzeitschicht (Datenbank, Transaktionsmanager, Scheduler) aus, während der Anwendungscode intakt bleibt. Ein Refactor schreibt den Code in eine moderne Sprache um, wobei die Geschäftslogik erhalten bleibt. Ein Retain belässt den Workload ganz bewusst auf dem Mainframe. Große Institutionen wenden in einem Portfolio normalerweise mehrere dieser Strategien an, anstatt sich auf eine einzige festzulegen.

Sollte ich meine COBOL-Anwendungen rehosten oder refactoren?

Das hängt davon ab, wie oft sich der Code ändert und was ein Fehler kostet. Rehosting ist schneller und risikoärmer, erhält jedoch sowohl den Legacy-Code als auch die Abhängigkeit von speziellem Know-how. Es eignet sich daher für stabile Workloads, bei denen Druck bezüglich Hardware oder Rechenzentrum besteht. Refactoring beseitigt die COBOL-Abhängigkeit dauerhaft und eignet sich für Workloads mit einem aktiven Change-Backlog, kostet jedoch mehr und scheitert, wenn die ursprünglichen Geschäftsregeln nie dokumentiert wurden. Entscheiden Sie pro Workload anhand der Änderungshistorie statt portfolioübergreifend.

Warum scheitern Migrationen von COBOL zu Java?

Selten wegen der Syntax. Sie scheitern, weil die Spezifikation nie schriftlich festgehalten wurde, sodass niemand beweisen kann, dass das neu geschriebene System korrekt ist; weil sich die Arithmetik zwischen gepackten Dezimalzahlen in COBOL und Fließkommazahlen in Java unterscheidet, was statt zu Abstürzen zu schleichenden Rundungsabweichungen führt; weil Test-Suites das aktuelle Verhalten auf Pfaden festschreiben, an die jemand beim Testen gedacht hat, anstatt das korrekte Verhalten über alle Pfade hinweg; weil die Kosten für eine regulatorische Neuzertifizierung erst spät erkannt werden; und weil die Experten, die das System verstehen, während des Programms in den Ruhestand gehen.

Wie lange dauert die Mainframe-Modernisierung?

Das hängt weit mehr davon ab, wie gut das bestehende System verstanden wird, als von der reinen Code-Menge. Für Portfolios mit aktueller Dokumentation und verfügbaren Fachexperten rechnet man in Quartalen. Bei Portfolios, in denen die Geschäftsregeln nur als Systemverhalten existieren, fließt die meiste Zeit in die Analyse, bevor die eigentliche Migration beginnt. Deshalb sind Dokumentation und Wissenserfassung zwingende Voraussetzungen und keine parallelen Projektstränge.

Ist es jemals richtig, einen Workload auf dem Mainframe zu belassen?

Ja. Stabile Workloads mit hohem Durchsatz, die sich selten ändern und günstig im Betrieb sind (Batch-Abrechnungen sind das deutlichste Beispiel), erfüllen oft bereits ihren Zweck, und eine Migration erhöht das Risiko, ohne neue Möglichkeiten zu bieten. Beibehalten ist eine legitime Strategie, wenn sie bewusst gewählt und dokumentiert wird. Es ist jedoch keine Strategie, einen Workload beizubehalten, den niemand erklären kann, da das Wissen dennoch verloren geht, wenn das Team in den Ruhestand geht.

So modernisieren Sie einen COBOL-Mainframe

Vier Strategien, was jede davon tatsächlich kostet und wie Sie erkennen, welche ein bestimmter Workload benötigt. Geschrieben für diejenigen, die die Entscheidung absegnen müssen.

Die meisten Ratschläge zur Mainframe-Modernisierung reduzieren sich auf eine einzige Frage: migrieren oder nicht. Diese Sichtweise ist der Grund, warum so viele Programme ins Stocken geraten. Ein großes Unternehmen hat nicht nur einen Mainframe-Workload, sondern Hunderte, und sie erfordern nicht alle die gleiche Behandlung. Die sinnvolle Entscheidung wird je Workload getroffen, und es gibt vier vertretbare Antworten.

Die vier Strategien

Rehost

Den Workload unverändert auf einen Emulator oder eine Cloud-Instanz verschieben, ohne den Code zu ändern.

Good for: Workloads, bei denen die Geschäftslogik noch korrekt ist und der Handlungsdruck durch Hardwarekosten, Kapazitätsengpässe oder einen Rechenzentrumsausstieg entsteht.
What it costs: Am schnellsten und risikoärmsten pro Workload. Der Code läuft weiter, sodass das Verhalten quasi systembedingt erhalten bleibt.
The catch: Sie haben das Problem verlagert, aber nicht gelöst. COBOL bleibt COBOL, die undokumentierten Geschäftsregeln bleiben undokumentiert, und die Personen, die sie verstehen, bleiben die einzigen, die sie verstehen. Das Rehosting eines Workloads, den Sie nicht erklären können, verschafft Ihnen lediglich Zeit und sonst nichts.

Replatform

Tauschen Sie die Laufzeitschicht (Datenbank, Transaktionsmanager, Scheduler) aus, während der Anwendungscode weitgehend intakt bleibt.

Good for: Um MIPS-basierten Lizenzen oder einem End-of-Life-Subsystem zu entgehen, wenn die Anwendungslogik selbst solide ist.
What it costs: Ein Mittelweg. Weniger Risiko als ein Rewrite, mehr Nutzen als Lift-and-Shift.
The catch: In den Schnittstellen zwischen Anwendungscode und Laufzeitumgebung stecken jahrzehntelange, undokumentierte Annahmen. Der Wechsel von Db2 zu PostgreSQL ist kein einfaches Suchen und Ersetzen; Isolationsstufen, Sortierfolgen und die Behandlung von Nullwerten unterscheiden sich auf eine Weise, die sich eher in falschen Zahlen als in Abstürzen äußert.

Refactoring

Den Code in einer modernen Sprache neu schreiben und dabei die Geschäftslogik erhalten.

Good for: Workloads, die häufig geändert werden müssen und bei denen der Mangel an COBOL-Ressourcen eher die Roadmap als den Betrieb einschränkt.
What it costs: Die höchsten Kosten und das größte Potenzial. Richtig umgesetzt, beseitigt dies die Abhängigkeit von speziellem Fachwissen dauerhaft.
The catch: Dies ist die Strategie, die öffentlich scheitert. Die Ursache für das Scheitern ist nie die Syntax, da Transpiler diese übernehmen. Das Problem ist, dass die Spezifikation nie dokumentiert wurde, sodass niemand beurteilen kann, ob das neue System korrekt arbeitet. Sie migrieren keinen Code, sondern rekonstruieren eine Spezifikation, die nur als Verhalten existiert.

Beibehalten

Den Workload bewusst auf dem Mainframe belassen.

Good for: Stabile Workloads mit hohem Durchsatz, die günstig im Betrieb sind und sich selten ändern. Batch-Abrechnungen sind oft das deutlichste Beispiel.
What it costs: Keine, wenn Sie sich bewusst dafür entscheiden und die Gründe dokumentieren.
The catch: Beibehalten ist eine echte Strategie und wird zu selten genutzt, da sie sich in einer Vorstandspräsentation schwer verkaufen lässt. Ein Beibehalten ohne Dokumentation ist jedoch keine Strategie, sondern nur ein Aufschub. Sie verlieren das Wissen trotzdem, wenn das Team in den Ruhestand geht.

So entscheiden Sie je Workload

Vier Fragen bestimmen, welche Strategie ein Workload benötigt. Beantworten Sie diese pro Anwendung, nicht pro Portfolio.

Wie oft wird dieser Code tatsächlich geändert?: Ziehen Sie die Änderungshistorie heran, keine Meinungen. Code, der seit acht Jahren nicht geändert wurde, ist ein Kandidat für Retain oder Rehost, unabhängig vom Alter der Sprache. Bei Code mit einer Warteschlange anstehender Änderungen macht sich ein Refactoring bezahlt.
Kann aktuell jemand erklären, was es tut?: Wenn die Antwort von ein oder zwei bestimmten Personen abhängt, ist noch keine Migrationsstrategie sicher. Dokumentation und Wissenssicherung sind Voraussetzungen, keine Ergebnisse, die erst nebenbei erstellt werden.
Was kosten Fehler?: Eine falsch gebuchte Zinsberechnung und ein langsamer Report stellen nicht dasselbe Risiko dar. Je höher die Kosten einer unbemerkten Verhaltensabweichung sind, desto mehr Überprüfung erfordert die Migration und desto stärker verschiebt sich die Wirtschaftlichkeit in Richtung Retain oder Rehost.
Was erzwingt die Veränderung eigentlich?: Hardwarekosten, eine Compliance-Frist, ein massiver Fachkräftemangel und eine Produkt-Roadmap erfordern jeweils unterschiedliche Strategien. Programme, die den zwingenden Grund nicht benennen können, wählen meist standardmäßig die teuerste Option.

Warum Migrationen von COBOL nach Java scheitern

Der Refactoring-Pfad verdient eine gesonderte Betrachtung, da er für die Schlagzeilen sorgt. Die wiederkehrenden Fehlermuster sind über alle Institutionen hinweg konsistent.

Die Spezifikation wurde nie schriftlich festgehalten

Vierzig Jahre an Anpassungen existieren nur im Code und nirgendwo sonst. Jede Neuentwicklung ist daher in erster Linie Archäologie und erst in zweiter Linie Softwareentwicklung. Teams, die diese Archäologie überspringen, entdecken die fehlenden Regeln erst in der Produktion.

Verhaltensabweichungen bleiben unbemerkt

Die gepackte Dezimalarithmetik von COBOL und die Gleitkommaarithmetik von Java runden nicht identisch. Differenzen von einem Cent pro Transaktion lösen keine Exceptions aus; sie führen am Quartalsende zu fehlerhaften Abstimmungen, lange nachdem die Migration für abgeschlossen erklärt wurde.

Tests bilden das aktuelle Verhalten ab, nicht das korrekte Verhalten

Eine erfolgreiche Test-Suite, die anhand des Legacy-Systems erstellt wurde, beweist, dass das neue System das Verhalten des alten Systems auf den Pfaden reproduziert, an die beim Testen jemand gedacht hat. Reale Portfolios enthalten Pfade, die seit einem Jahrzehnt niemand mehr bewusst ausgeführt hat.

Regulatorische Neuzertifizierung ist nicht kostenlos

Bei Banken, Versicherungen und Behörden gilt ein neu geschriebenes System für Audit-Zwecke häufig als neues System. Diese Kosten gehören von Anfang an in den Business Case, nicht erst als Erkenntnis im neunten Monat.

Die Experten scheiden mitten im Programm aus

Mehrjährige Programme überschneiden sich direkt mit dem Renteneintritt der Personen, auf die sie angewiesen sind. Dieses Wissen muss vor Beginn des Programms gesichert werden, da es sonst nicht mehr verfügbar ist, wenn es am dringendsten benötigt wird.

Die Frage, die die Wirtschaftlichkeit verändert

Jede der obigen Strategien unterliegt derselben Einschränkung: Lässt sich beweisen, dass das System noch immer das tut, was es vorher tat? Tests prüfen Stichproben des Eingaberaums. Formale Verifikation betrachtet ihn in seiner Gesamtheit und beweist, dass der modernisierte Pfad für jede Eingabe dieselbe Ausgabe erzeugt wie der bisherige. Wenn dieser Beweis vorliegt, ist Refactoring kein Sprung ins Ungewisse mehr, sondern eine klar umrissene technische Aufgabe, und die Antwort auf die obige Frage nach den Kosten von Fehlern ändert sich. Fehlt dieser Beweis, ist eine konservative Herangehensweise die richtige Wahl.

Wo Hypercubic ins Spiel kommt

Wir entwickeln für die Archäologie und den Beweis, in dieser Reihenfolge. HyperDocs rekonstruiert die Dokumentation aus COBOL-, PL/I- und JCL-Quellcode. HyperTwin erfasst das Wissen Ihrer Senior-Entwickler, bevor diese in den Ruhestand gehen. Hopper übernimmt den täglichen z/OS-Betrieb. HyperLoop führt die eigentliche Migration mit Korrektheitsbeweisen auf Zeilenebene durch. Wenn Sie früh genug ansetzen, sodass die ersten beiden wichtiger sind als die letzten beiden, ist dies die ehrliche Reihenfolge.

Häufig gestellte Fragen

Was sind die vier Strategien zur Mainframe-Modernisierung?: Rehost, Replatform, Refactor und Retain. Ein Rehost verschiebt den Workload auf einen Emulator oder eine Cloud-Instanz, ohne den Code zu ändern. Ein Replatform tauscht die Laufzeitschicht (Datenbank, Transaktionsmanager, Scheduler) aus, während der Anwendungscode intakt bleibt. Ein Refactor schreibt den Code in eine moderne Sprache um, wobei die Geschäftslogik erhalten bleibt. Ein Retain belässt den Workload ganz bewusst auf dem Mainframe. Große Institutionen wenden in einem Portfolio normalerweise mehrere dieser Strategien an, anstatt sich auf eine einzige festzulegen.
Sollte ich meine COBOL-Anwendungen rehosten oder refactoren?: Das hängt davon ab, wie oft sich der Code ändert und was ein Fehler kostet. Rehosting ist schneller und risikoärmer, erhält jedoch sowohl den Legacy-Code als auch die Abhängigkeit von speziellem Know-how. Es eignet sich daher für stabile Workloads, bei denen Druck bezüglich Hardware oder Rechenzentrum besteht. Refactoring beseitigt die COBOL-Abhängigkeit dauerhaft und eignet sich für Workloads mit einem aktiven Change-Backlog, kostet jedoch mehr und scheitert, wenn die ursprünglichen Geschäftsregeln nie dokumentiert wurden. Entscheiden Sie pro Workload anhand der Änderungshistorie statt portfolioübergreifend.
Warum scheitern Migrationen von COBOL zu Java?: Selten wegen der Syntax. Sie scheitern, weil die Spezifikation nie schriftlich festgehalten wurde, sodass niemand beweisen kann, dass das neu geschriebene System korrekt ist; weil sich die Arithmetik zwischen gepackten Dezimalzahlen in COBOL und Fließkommazahlen in Java unterscheidet, was statt zu Abstürzen zu schleichenden Rundungsabweichungen führt; weil Test-Suites das aktuelle Verhalten auf Pfaden festschreiben, an die jemand beim Testen gedacht hat, anstatt das korrekte Verhalten über alle Pfade hinweg; weil die Kosten für eine regulatorische Neuzertifizierung erst spät erkannt werden; und weil die Experten, die das System verstehen, während des Programms in den Ruhestand gehen.
Wie lange dauert die Mainframe-Modernisierung?: Das hängt weit mehr davon ab, wie gut das bestehende System verstanden wird, als von der reinen Code-Menge. Für Portfolios mit aktueller Dokumentation und verfügbaren Fachexperten rechnet man in Quartalen. Bei Portfolios, in denen die Geschäftsregeln nur als Systemverhalten existieren, fließt die meiste Zeit in die Analyse, bevor die eigentliche Migration beginnt. Deshalb sind Dokumentation und Wissenserfassung zwingende Voraussetzungen und keine parallelen Projektstränge.
Ist es jemals richtig, einen Workload auf dem Mainframe zu belassen?: Ja. Stabile Workloads mit hohem Durchsatz, die sich selten ändern und günstig im Betrieb sind (Batch-Abrechnungen sind das deutlichste Beispiel), erfüllen oft bereits ihren Zweck, und eine Migration erhöht das Risiko, ohne neue Möglichkeiten zu bieten. Beibehalten ist eine legitime Strategie, wenn sie bewusst gewählt und dokumentiert wird. Es ist jedoch keine Strategie, einen Workload beizubehalten, den niemand erklären kann, da das Wissen dennoch verloren geht, wenn das Team in den Ruhestand geht.

Ermitteln Sie, welche Workloads zuerst migriert werden.

Sprechen Sie mit unserem Team über die Zuordnung Ihres Portfolios zu den vier Strategien, oder beginnen Sie mit dem Glossar, wenn Sie ein internes Vokabular aufbauen.

Demo anfordern Glossar lesen