Als ich bei Heise die Überschrift „Mehr als COBOL zu Java: Googles KI-Plan für Mainframes“ gelesen habe, war mein erster Gedanke tatsächlich positiv. Endlich einmal ein Beitrag über Mainframe-Modernisierung, bei dem nicht schon in der Überschrift suggeriert wird, dass irgendwo ein paar Millionen Zeilen COBOL herumliegen, die nur darauf warten, von einer künstlichen Intelligenz nach Java übersetzt zu werden.

Denn genau diese Vorstellung begleitet die Diskussion über Mainframe-Modernisierung seit Jahren. Auf der einen Seite steht angeblich die alte Welt aus COBOL, CICS, Db2 und VSAM, auf der anderen Seite warten Java, Microservices und Cloud. Dazwischen benötigt man nur noch einen möglichst intelligenten Konverter, und wenn dieser seine Arbeit erledigt hat, ist die Modernisierung abgeschlossen.

So einfach war es nie.

Google scheint das inzwischen ebenfalls verstanden zu haben. Der neue Ansatz besteht deshalb nicht einfach aus einem weiteren Code-Konverter. Google spricht über Analyse, Abhängigkeiten, Geschäftsregeln, Daten, Transformation und vor allem darüber, wie sich eine Anwendung zunächst besser verstehen lässt, bevor sie verändert wird. In der eigenen Beschreibung des Ansatzes wird ausdrücklich darauf eingegangen, dass Mainframe-Modernisierung weit über die reine Übersetzung von Sourcecode hinausgeht.

Das finde ich grundsätzlich richtig.

Wer sich Googles Mainframe Assessment Tool genauer ansieht, findet durchaus interessante Ansätze. Das Werkzeug soll Abhängigkeiten zwischen Anwendungen und Datenbeständen identifizieren, Geschäftsregeln aus bestehendem Code extrahieren, technische Dokumentation erzeugen und fachliche beziehungsweise technische Domänen innerhalb größerer Anwendungslandschaften sichtbar machen.

Gerade diesen Teil halte ich für ausgesprochen spannend. In vielen gewachsenen Mainframe-Umgebungen liegt das eigentliche Problem nämlich gar nicht darin, dass COBOL grundsätzlich schwierig zu lesen wäre. Das Problem besteht vielmehr darin, dass Anwendungen über Jahrzehnte gewachsen sind und das Wissen über ihre Zusammenhänge dabei immer weiter verteilt wurde.

Ein Programm ruft ein anderes auf, dieses verwendet mehrere Copybooks, ein Batchprozess aktualisiert nachts Daten, die am folgenden Morgen von einer CICS-Anwendung verarbeitet werden, irgendwo existiert noch eine Assembler-Routine und einige JCL-Prozeduren haben sich über Jahre zu einem kleinen Paralleluniversum entwickelt.

Das alles kann technisch hervorragend funktionieren und trotzdem nur noch von wenigen Menschen vollständig verstanden werden.

Wenn KI dabei helfen kann, dieses Wissen wieder sichtbar zu machen, dann ist das für mich einer der sinnvollsten Anwendungsfälle generativer KI auf dem Mainframe.

Bis hierhin bin ich also durchaus bei Google.

Dann beginnt allerdings mein Problem mit dem Ansatz.

Die Analyse ist offen. Das Ergebnis erstaunlicherweise weniger.

Google schreibt selbst, dass Mainframe-Modernisierung kein einfaches Code-to-Code-Problem sei. Gleichzeitig ist die Zielrichtung der eigenen Produktstrategie bemerkenswert eindeutig.

Die Dokumentation zum Mainframe Assessment Tool beschreibt das Werkzeug letztlich im Kontext einer Modernisierung beziehungsweise Migration von Mainframe-Anwendungen in Richtung Google Cloud. Auch die zentrale Produktseite spricht sehr deutlich über den Weg vom Mainframe in die Google Cloud.

Das ist vollkommen legitim.

Google ist schließlich kein unabhängiges Beratungsunternehmen für Mainframe-Strategien, sondern einer der größten Cloud-Anbieter der Welt. Natürlich entwickelt Google Werkzeuge, deren erfolgreicher Einsatz am Ende möglichst häufig dazu führt, dass Workloads auf Google Cloud betrieben werden.

Nur sollte man dann sauber zwischen zwei Dingen unterscheiden.

Das eine ist Mainframe-Modernisierung.

Das andere ist Mainframe-Migration zu Google Cloud.

Beides kann zusammengehören. Es muss aber nicht.

Und genau diese Differenzierung vermisse ich in der Berichterstattung bei Heise.

Denn ausgerechnet ein technologisches Fachmedium sollte an dieser Stelle fragen, ob eine Plattformmigration tatsächlich die logische Konsequenz einer gelungenen Analyse ist.

Für mich ist sie das nicht.

Eine wirklich ergebnisoffene Analyse müsste nämlich auch zu dem Ergebnis kommen können, dass eine Anwendung auf z/OS bleiben sollte.

Vielleicht wird sie dort über APIs geöffnet. Vielleicht bekommt sie eine moderne CI/CD-Pipeline. Vielleicht werden einzelne Komponenten in Java neu entwickelt. Vielleicht werden bestimmte Funktionen ausgelagert. Vielleicht entsteht eine hybride Architektur. Vielleicht wird die Anwendung technisch bereinigt und anschließend noch zehn Jahre auf dem Mainframe betrieben.

Und vielleicht zeigt die Analyse sogar, dass eine Migration keinerlei wirtschaftlichen Sinn ergibt.

Auch das wäre ein vollkommen legitimes Modernisierungsergebnis.

Genau deshalb halte ich die Gleichsetzung von Modernisierung und Plattformwechsel für einen der größten Denkfehler in dieser ganzen Diskussion.

Interessanterweise warnt Gartner genau vor dieser Vereinfachung

Besonders bemerkenswert wird die Sache, wenn man Googles Aussagen mit einer aktuellen Gartner-Einschätzung vergleicht.

Gartner prognostizierte im Juni 2026, dass mehr als 70 Prozent der 2026 gestarteten Mainframe-Exit-Projekte die erwarteten Vorteile nicht erreichen werden. Als wesentlichen Grund nennt Gartner ausdrücklich eine Überschätzung dessen, was generative KI bei komplexen Mainframe-Transformationen leisten kann. Nachzulesen ist diese Einschätzung hier.

Gartner spricht dabei von einer wachsenden Lücke zwischen den Marketingversprechen generativer KI und ihrer tatsächlichen Fähigkeit, komplexe Legacy-Systeme zu transformieren und zu migrieren. Interessant ist vor allem die daraus folgende Überlegung: Für viele Unternehmen könnte generative KI sinnvoller dazu eingesetzt werden, bestehende Mainframe-Systeme auf ihrer vorhandenen Plattform zu modernisieren, anstatt damit möglichst schnell einen vollständigen Exit zu erreichen.

Und genau hier hätte es für Heise eigentlich richtig interessant werden können.

Denn was wäre journalistisch spannender gewesen, als Googles neue Strategie mit genau dieser Einschätzung zu konfrontieren?

Google sagt sinngemäß: Wir können mit KI Mainframe-Anwendungen analysieren, transformieren, testen und anschließend kontrollierter in die Cloud überführen.

Gartner sagt gleichzeitig: Vorsicht, gerade die Überschätzung der Möglichkeiten generativer KI könnte dazu führen, dass ein erheblicher Teil solcher Mainframe-Exit-Projekte seine Ziele verfehlt.

Das wäre eine hervorragende Ausgangslage für einen wirklich interessanten Fachartikel gewesen.

Stattdessen bleibt bei mir nach dem Lesen des Heise-Beitrags vor allem der Eindruck zurück, dass Googles Produktankündigung relativ geradlinig weitergegeben wird.

Und da frage ich mich tatsächlich, was sich der Autor bei Heise bei dieser Gelegenheit gedacht hat.

Nicht weil die Informationen falsch wären. Und auch nicht, weil Google nichts Interessantes vorgestellt hätte.

Ganz im Gegenteil.

Gerade weil die Technologie interessant ist, hätte sie eine wesentlich kritischere journalistische Einordnung verdient.

Ein Fachmedium sollte meiner Meinung nach nicht nur wiedergeben, welche Funktionen ein Hersteller ankündigt. Es sollte gerade bei einem derart strategischen Thema auch fragen, welche Annahmen dahinterstehen, wo die Grenzen liegen und welche wirtschaftlichen Interessen der Anbieter naturgemäß verfolgt.

Genau diese zweite Ebene fehlt mir.

Geschäftsregeln aus Code extrahieren? Unbedingt. Aber bitte nicht mit Wahrheit verwechseln.

Ein gutes Beispiel dafür ist Googles Business Rules Extraction.

Das Mainframe Assessment Tool kann bestehenden Anwendungscode analysieren und daraus Geschäftsregeln in menschenlesbarer Form erzeugen. Google beschreibt diesen Prozess ausführlicher genau hier. Gerade bei Anwendungen, deren fachliche Dokumentation über Jahre nicht mehr konsequent gepflegt wurde, kann das einen erheblichen Nutzen bringen.

Nur sollte man an dieser Stelle sehr genau hinschauen.

Eine KI kann aus einem Programm relativ gut ableiten, was dieses Programm tut.

Sie kann Bedingungen erkennen, Berechnungen nachvollziehen, Entscheidungswege darstellen und Abhängigkeiten sichtbar machen.

Was sie nicht automatisch weiß, ist, warum diese Logik dort steht.

Das ist bei Legacy-Anwendungen ein entscheidender Unterschied.

Vielleicht wurde eine bestimmte Regel 1998 aufgrund einer gesetzlichen Vorgabe eingebaut. Vielleicht existiert diese Vorgabe längst nicht mehr. Vielleicht entstand eine Sonderbehandlung aufgrund einer Einschränkung eines damaligen Fremdsystems. Vielleicht gibt es dieselbe Geschäftsregel noch einmal an drei anderen Stellen. Vielleicht sieht eine Berechnung im Sourcecode vollkommen plausibel aus, obwohl der Fachbereich sie seit Jahren eigentlich anders verstanden hat.

Und manchmal ist eine scheinbar merkwürdige Konstruktion eben gar kein historischer Ballast, sondern das Ergebnis von dreißig Jahren Erfahrung mit seltenen Ausnahmefällen.

Gerade deshalb finde ich einen Punkt in Googles eigener Dokumentation ausgesprochen wichtig. Google sieht ausdrücklich eine menschliche Validierung der extrahierten Geschäftsregeln vor. Regeln können geprüft und beispielsweise als validiert oder nicht mehr relevant eingeordnet werden. Erst danach sollte daraus eine Grundlage für die weitere Modernisierung werden.

Das ist fachlich absolut vernünftig.

Es zeigt aber gleichzeitig etwas, das in vielen Diskussionen über KI-basierte Modernisierung gerne verloren geht:

Zwischen „KI extrahiert Geschäftsregeln“ und „KI versteht die Anwendung“ liegt ein erheblicher Unterschied.

Und genau diesen Unterschied hätte ich auch im Heise-Artikel gerne deutlicher gesehen.

Auch der von KI generierte Code muss am Ende jemand verstehen

Noch interessanter wird es bei der eigentlichen Transformation.

Google beschreibt, dass der erzeugte beziehungsweise transformierte Code anschließend überprüft und validiert werden muss. Dabei geht es unter anderem um logische Korrektheit, Architektur, Security und Performance.

Auch das ist vollkommen richtig.

Es führt allerdings zu einer Frage, die bei all der Begeisterung über KI erstaunlich selten gestellt wird:

Wer soll diese Prüfung eigentlich durchführen?

Dafür braucht man Menschen, die die bestehende Anwendung verstehen.

Man benötigt gleichzeitig Menschen, die die neue Architektur beurteilen können.

Und im Idealfall benötigt man Spezialisten, die beide Welten miteinander vergleichen können.

Damit löst KI ausgerechnet eines der schwierigsten Probleme vieler Mainframe-Modernisierungen nicht automatisch: den Mangel an erfahrenen Leuten, die genügend fachliches und technisches Wissen besitzen, um zu beurteilen, ob die transformierte Anwendung wirklich korrekt ist.

Die KI kann Arbeit beschleunigen. Sie kann Dokumentation erzeugen, Zusammenhänge sichtbar machen und Teile der Implementierung übernehmen.

Die Verantwortung für das Ergebnis bleibt trotzdem beim Menschen.

Das gilt übrigens nicht nur für Google. Es gilt grundsätzlich für jede KI-gestützte Code-Transformation.

Und genau deshalb bin ich immer etwas skeptisch, wenn suggeriert wird, dass sich der Fachkräftemangel im Mainframe-Bereich durch generative KI quasi nebenbei erledigen könnte.

Das Gegenteil kann zumindest während einer Transformation der Fall sein. Plötzlich brauche ich nicht weniger Wissen, sondern gleichzeitig Wissen über die alte und über die neue Welt.

Dual Run ist ein gutes Werkzeug, aber kein Beweis für vollständige Gleichwertigkeit

Googles Dual-Run-Ansatz halte ich grundsätzlich ebenfalls für sinnvoll.

Die Idee besteht darin, bestehendes und modernisiertes System parallel zu betreiben und reale Transaktionen beziehungsweise deren Ergebnisse miteinander zu vergleichen. Google beschreibt diesen Ansatz ebenfalls im Zusammenhang mit Validierung und Modernisierung.

Das kann bei einer Migration erheblich dazu beitragen, Abweichungen zu erkennen.

Nur gilt auch hier: Ein technisches Verfahren sollte nicht mehr versprechen, als es tatsächlich leisten kann.

Produktionsdaten zeigen, was in einem bestimmten Zeitraum tatsächlich passiert ist.

Sie zeigen aber nicht zwangsläufig alles, was passieren könnte.

Vielleicht gibt es einen bestimmten Geschäftsvorfall nur einmal im Jahr. Vielleicht tritt eine spezielle Kombination nur beim Jahresabschluss auf. Vielleicht existieren seltene Storno-, Recovery- oder Fehlerfälle. Vielleicht spielt ein bestimmter Prozess nur dann eine Rolle, wenn ein vorgelagertes System ausfällt.

Wer lange genug mit gewachsenen Anwendungen gearbeitet hat, weiß, dass gerade die seltenen Ausnahmen häufig die interessantesten Stellen sind.

Dual Run kann deshalb ein hervorragender Bestandteil der Qualitätssicherung sein.

Er ersetzt aber weder ein vollständiges Testkonzept noch Fachwissen noch eine saubere Abnahme.

Auch hier hätte eine kritischere Einordnung durch Heise dem Artikel gutgetan.

Und warum sollen die Daten eigentlich zwangsläufig umziehen?

Dasselbe gilt für Googles Werkzeuge zur Datenmigration.

Google beschreibt im Rahmen seiner Mainframe-Modernisierungsstrategie Möglichkeiten, Daten vom Mainframe in Dienste der Google Cloud zu übertragen und anschließend beispielsweise für neue Anwendungen oder analytische Verfahren zu nutzen. Einen Überblick über die unterschiedlichen Migrationsangebote gibt Google unter https://docs.cloud.google.com/docs/migration.

Technisch ist das zweifellos interessant.

Meine erste Frage wäre trotzdem nicht, wie man die Daten dorthin bekommt.

Meine erste Frage wäre:

Warum sollen sie überhaupt dorthin?

Wenn BigQuery einen konkreten analytischen Anwendungsfall erheblich verbessert, kann das sinnvoll sein.

Wenn eine neue Anwendung eine andere Datenbankarchitektur benötigt, ebenfalls.

Wenn sich Betriebskosten nachweislich reduzieren lassen, sollte man darüber sprechen.

Aber Datenmigration ist kein Selbstzweck.

Ein Db2-System wird nicht dadurch technisch problematisch, dass es auf einem Mainframe läuft. Ein VSAM-KSDS ist nicht automatisch schlecht, nur weil dessen grundlegendes Konzept älter ist als Kubernetes.

Die richtige Technologie hängt vom Zugriffsmuster, vom Transaktionsvolumen, von Verfügbarkeitsanforderungen, von bestehenden Anwendungen und nicht zuletzt von den Kosten ab.

Manchmal ist die modernste Entscheidung deshalb erstaunlicherweise diejenige, etwas nicht zu verändern.

Vendor Lock-in verschwindet nicht. Er zieht nur um.

Ein weiterer Punkt fehlt mir in dieser Diskussion fast vollständig.

Mainframe-Systemen wird gerne ihre proprietäre Architektur vorgeworfen. Dabei entsteht teilweise der Eindruck, eine Migration in die Cloud würde diese Abhängigkeiten grundsätzlich beseitigen.

Das halte ich für eine ausgesprochen kreative Interpretation von Cloud-Architektur.

Wer seine Anwendungen intensiv mit BigQuery, Cloud SQL, AlloyDB, Google-spezifischen APIs, Client Libraries, Observability-Diensten und weiteren Plattformkomponenten verbindet, schafft selbstverständlich neue technische und wirtschaftliche Abhängigkeiten.

Diese können vollkommen sinnvoll sein.

Vielleicht überwiegen ihre Vorteile sogar deutlich.

Dann sollte man sie aber genauso nüchtern bewerten wie die bestehenden Abhängigkeiten auf dem Mainframe.

Ein Vendor Lock-in wird nicht automatisch besser, nur weil er jetzt eine REST-API besitzt.

Auch dieses Thema hätte sich für einen technisch kritischen Heise-Artikel geradezu angeboten. Denn eine seriöse Modernisierungsdiskussion sollte nicht nur fragen, welche Abhängigkeiten verschwinden, sondern auch, welche neuen entstehen.

Auch die Kostenrechnung verdient mehr als ein Marketingversprechen

Ähnlich verhält es sich mit den Kosten.

Cloud-Anbieter argumentieren verständlicherweise mit Flexibilität, Skalierbarkeit und potenziellen Kostenvorteilen. Auch Google positioniert seine Mainframe-Modernisierung entsprechend.

Nur kann man die wirtschaftliche Frage nicht beantworten, indem man Mainframe-Kosten auf der einen Seite und virtuelle CPUs oder Speicherpreise auf der anderen Seite gegenüberstellt.

Zu einer seriösen Rechnung gehören auch die Kosten der eigentlichen Migration, der oftmals jahrelange Parallelbetrieb, Netzwerk und Datenübertragung, Hochverfügbarkeit, Disaster Recovery, Security, Observability, Softwarelizenzen, Support und natürlich der Aufbau beziehungsweise Einkauf neuer Skills.

Dazu kommen Risiken, die sich nur schwer in Tabellen eintragen lassen.

Wie viel kostet es beispielsweise, wenn eine fachliche Regel bei der Transformation falsch interpretiert wird?

Wie bewertet man einen Fehler, der erst Monate nach einer Migration bei einem seltenen Geschäftsvorfall sichtbar wird?

Und wie teuer ist eine Modernisierung, wenn sich nach zwei Jahren herausstellt, dass das ursprünglich erwartete Einsparpotenzial nicht erreicht werden kann?

Das bedeutet nicht, dass der Mainframe automatisch günstiger ist.

Es bedeutet lediglich, dass man es rechnen muss.

Und zwar für den konkreten Anwendungsfall.

Genau hier hätte Heise seine eigentliche Aufgabe gehabt

Damit komme ich zurück zu dem Punkt, der mich an dem Artikel am meisten stört.

Google macht aus meiner Sicht nichts Ungewöhnliches.

Google entwickelt technisch interessante Produkte und zeigt anschließend, wie sich damit Mainframe-Workloads in die Google Cloud bringen lassen.

Das ist das Geschäftsmodell.

Ich erwarte von Google keine neutrale Plattformberatung.

Von Heise erwarte ich aber durchaus eine gewisse journalistische Distanz.

Der Beitrag hätte beispielsweise fragen können, welche Anwendungen überhaupt geeignete Kandidaten für eine solche Migration sind. Er hätte untersuchen können, wo die Grenzen der automatisierten Business-Rule-Extraktion liegen. Man hätte nach den Kosten des Parallelbetriebs fragen können. Man hätte thematisieren können, welche personellen Kompetenzen für die Validierung der KI-Ergebnisse benötigt werden.

Und vor allem hätte man die vielleicht wichtigste Frage stellen können:

Was passiert eigentlich, wenn die Analyse ergibt, dass der Mainframe die wirtschaftlich und technisch sinnvollste Plattform bleibt?

Diese Möglichkeit kommt in einer ernsthaften Modernisierungsstrategie zwingend vor.

In einem Cloud-Migrationsangebot naturgemäß weniger.

Genau diese Unterscheidung hätte ich von einem Fachmedium erwartet.

Besonders irritierend ist das vor dem Hintergrund dieser Gartner-Einschätzung. Wenn ein Analystenhaus wenige Wochen zuvor ausdrücklich davor warnt, dass ein großer Teil neu gestarteter Mainframe-Exit-Projekte seine erwarteten Vorteile aufgrund überzogener Erwartungen an generative KI verfehlen könnte, dann sollte das bei einem Artikel über eine KI-gestützte Mainframe-to-Cloud-Strategie aus meiner Sicht mehr als eine Randnotiz sein.

Man hätte Google damit konfrontieren können.

Man hätte fragen können, wie sich die neuen Werkzeuge genau von den Ansätzen unterscheiden, vor denen Gartner warnt.

Man hätte nach Referenzprojekten fragen können.

Nach tatsächlich erreichten Einsparungen.

Nach Projektlaufzeiten.

Nach den Grenzen der Automatisierung.

Oder schlicht danach, wie Google entscheidet, welche Anwendungen nicht migriert werden sollten.

Das hätte den Beitrag nicht zu einem Anti-Google-Artikel gemacht.

Es hätte ihn schlicht zu einem besseren Fachartikel gemacht.

Und genau deshalb ist meine Kritik an Heise an dieser Stelle auch deutlicher als meine Kritik an Google.

Google verkauft eine Lösung. Das darf Google.

Ein Fachmedium sollte diese Lösung einordnen.

Googles Ansatz ist interessanter, als meine Kritik vielleicht vermuten lässt

Dabei möchte ich ausdrücklich nicht den Eindruck erwecken, Googles Ansatz grundsätzlich abzulehnen.

Ganz im Gegenteil.

Das Mainframe Assessment Tool halte ich für technologisch interessant. Dependency Mapping, automatisierte Dokumentation, Business Rule Extraction und KI-gestützte Analyse großer Codebestände adressieren reale Probleme.

Dass Google diesen Bereich aktiv weiterentwickelt, lässt sich auch an den Release Notes erkennen. Der Funktionsumfang wird erweitert, größere Codebestände können verarbeitet werden und zusätzliche Mainframe-Artefakte werden berücksichtigt.

Das zeigt, dass hier ernsthaft Entwicklungsarbeit investiert wird und es keineswegs nur um eine Marketingdemo geht.

Gerade deshalb wäre es schade, das Ganze auf eine einfache Botschaft zu reduzieren:

KI versteht den Mainframe und bringt ihn anschließend in die Cloud.

Der wirklich spannende Teil liegt für mich nämlich davor.

Wenn KI dabei hilft, ein komplexes System wieder zu verstehen, Abhängigkeiten sichtbar zu machen, Geschäftslogik zu dokumentieren und verloren gegangenes Wissen zurückzugewinnen, dann entsteht daraus zunächst einmal eine wesentlich bessere Entscheidungsgrundlage.

Und genau an dieser Stelle sollte eine wirklich ergebnisoffene Modernisierung beginnen.

Vielleicht führt diese Analyse anschließend zu Google Cloud.

Vielleicht führt sie zu einer hybriden Architektur.

Vielleicht zu Java auf einer anderen Plattform.

Vielleicht zu einer Modernisierung auf z/OS.

Vielleicht werden einige Komponenten ausgelagert und andere bewusst nicht verändert.

Und vielleicht lautet das Ergebnis für einzelne Anwendungen sogar:

Wir lassen sie genau dort, wo sie sind.

Auch das kann eine moderne Architekturentscheidung sein.

Es ist sogar manchmal die wirtschaftlich vernünftigste.

Deshalb stimme ich der Überschrift des Heise-Artikels am Ende ausdrücklich zu:

Mainframe-Modernisierung ist mehr als COBOL zu Java.

Aber dann sollten wir den Gedanken konsequent zu Ende führen.

Sie ist eben auch mehr als Mainframe zu Google Cloud.

Eine echte Modernisierungsstrategie beginnt für mich deshalb weder mit Java noch mit Kubernetes, Gemini oder der Auswahl eines Hyperscalers.

Sie beginnt mit einer wesentlich einfacheren Frage:

Welches Problem wollen wir eigentlich lösen?

Danach kann man analysieren, welche Technologie dieses Problem am besten löst.

Wenn die Antwort Google Cloud lautet, ist das vollkommen in Ordnung.

Wenn die Antwort z/OS lautet, sollte das genauso in Ordnung sein.

Wer die Zielplattform allerdings bereits festgelegt hat, bevor diese Frage beantwortet wurde, betreibt aus meiner Sicht keine wirklich ergebnisoffene Modernisierung.

Er betreibt Migration.

Und genau diesen Unterschied hätte ich mir von Heise sehr viel deutlicher herausgearbeitet gewünscht.

Über den Autor: Uwe Graf ist Head of Consulting bei der EasiRun Europa GmbH und gilt auf LinkedIn als eine der profiliertesten Stimmen in Sachen Mainframe-Modernisierung. Seine Beiträge sind fachlich präzise, pointiert – und unverkennbar durch den kleinen Dino, der als Symbol für den Brückenschlag zwischen Tradition und Innovation steht. Für sein Engagement in der Mainframe-Community wurde er 2025 sowohl als IBM Champion als auch als „Influential Mainframer“ von planetmainframe.com ausgezeichnet