Google Cloud lehnt den Mainframe-Big-Bang zugunsten eines KI-gestützten Migrationspfads ab

Google Cloud hat eine vierstufige Alternative zu riskanten Mainframe-Migrationen vorgestellt, die vor der Umschaltung KI-Analyse, Codegenerierung, Datenkonvertierung und parallele Validierung nutzt.

Der Vorschlag stellt eine vertraute Wahl infrage. Unternehmen können veraltete Systeme weiter betreiben oder eine groß angelegte Migration versuchen, deren Abhängigkeiten erst sichtbar werden, nachdem die Arbeiten begonnen haben. Google argumentiert, dass keine der beiden Optionen das schwierigste Problem löst: zu verstehen, was das bestehende System tatsächlich tut.

Die Antwort verknüpft das Mainframe Assessment Tool, Gemini CLI, Mainframe Connector und Dual Run zu einem durchgängigen Prozess. Teams erfassen zunächst Geschäftsregeln und Abhängigkeiten. Anschließend entwickeln sie Cloud-Anwendungen auf Basis geprüfter Anforderungen, übertragen die relevanten Daten und vergleichen beide Umgebungen unter realen Arbeitslasten.

Diese Abfolge macht daraus mehr als eine weitere Ankündigung zur Codekonvertierung. Der zentrale Wettbewerb lautet iterative Modernisierung gegen die Big-Bang-Migration, nicht Cloud-Infrastruktur gegen Mainframe-Hardware.

Google sieht sich zudem etablierten Alternativen gegenüber. IBM setzt KI ein und bewahrt zugleich eine zentrale Rolle für IBM Z. AWS bewirbt einen agentischen Dienst, der generierte Anforderungen und Code bis zu den Mainframe-Quellen zurückverfolgt. Jeder Anbieter erkennt an, dass Codegenerierung allein nicht klären kann, ob ein Ersatzsystem korrekt ist.

Die entscheidende Frage lautet daher nicht, ob Gemini COBOL übersetzen kann. Sie lautet, ob Googles vernetzter Workflow jahrzehntelang gewachsenes, verborgenes Geschäftsverhalten bewahren kann und Unternehmen zugleich eine Modernisierung in überschaubaren Schritten ermöglicht.

Google Cloud verbindet vier Tools zu einem Migrationspfad

Die entscheidende Veränderung ist die Verknüpfung von Bewertung, Generierung, Datenübertragung und Produktionsvalidierung.

Googles Modernisierungsframework beginnt mit Reverse Engineering. Das Mainframe Assessment Tool untersucht Quellcode, Datenbankstrukturen, Transaktionsmonitore, Scheduler-Konfigurationen und Beziehungen zwischen Assets.

Es unterstützt COBOL-Programme, Copybooks, JCL-Jobs, Prozeduren, Includes und verwandte Artefakte. Das Tool verwendet Gemini, um aus diesem Material Zusammenfassungen, technische Spezifikationen und vorgeschlagene Geschäftsregeln zu generieren.

Geschäftsregeln sind die innerhalb einer Anwendung codierten Richtlinien, etwa Anspruchsvoraussetzungen, Zinsberechnungen oder Entscheidungen zur Weiterleitung von Transaktionen. Sie sind wichtig, weil das beobachtbare Verhalten eines alten Programms oft über seine erhaltene Dokumentation hinausgeht.

Google zufolge können Teams extrahierte Regeln prüfen, filtern und validieren, bevor sie sie exportieren. Dieser menschliche Kontrollpunkt unterscheidet den Vorschlag von einer bloßen Anweisung, jede Zeile in Java oder eine andere moderne Sprache zu übersetzen.

Die Bewertung kann einen Bestand zudem in Geschäftsdomänen und kleinere migrierbare Einheiten aufteilen. Eine migrierbare Einheit ist eine abgegrenzte Sammlung aus Programmen, Daten und Abhängigkeiten, die gemeinsam verschoben werden kann, ohne angrenzende Dienste zu beeinträchtigen.

Diese Aufteilung schafft die Grundlage für ein iteratives Programm. Eine Bank könnte zunächst einen Reporting-Flow isolieren, bevor sie die Zahlungsautorisierung anfasst. Ein Versicherer könnte einen Dokumentverarbeitungsdienst migrieren, während die Schadenregulierung auf dem Mainframe bleibt.

Nach der Bewertung unterstützt Gemini CLI das Forward Engineering. Das bedeutet, dass Teams validierte Anforderungen nutzen, um eine Zielarchitektur zu planen und neuen Code zu generieren, anstatt die alte Codebasis als Zielentwurf zu behandeln.

Der Workflow kann Datenmodelle und Dienste für Cloud Run, Google Kubernetes Engine, Compute Engine, BigQuery, Spanner, AlloyDB und Cloud SQL vorschlagen. Diese Vorschläge erfordern weiterhin eine Architekturprüfung, denn eine generierte Empfehlung ist keine betriebliche Entscheidung.

Mainframe Connector übernimmt ein weiteres, häufig unterschätztes Problem. Er kopiert und konvertiert Mainframe-Daten, einschließlich EBCDIC-codierter Datensätze, in Formate, die Google-Dienste verwenden können.

EBCDIC ist eine Zeichencodierung, die mit IBM-Mainframe-Umgebungen verbunden ist. Die korrekte Konvertierung erfordert mehr als eine Änderung der Textdarstellung, da Datensätze gepackte Dezimalzahlen, Copybook-Layouts und anwendungsspezifische Konventionen enthalten können.

Dual Run schließt den vorgeschlagenen Kreislauf. Es führt Arbeitslasten sowohl in der bestehenden Mainframe-Umgebung als auch in der Cloud-Umgebung aus und vergleicht anschließend ihre Ergebnisse vor der Produktionsumschaltung.

Der vernetzte Prozess verändert, worauf Teams ihr Vertrauen stützen. Statt einer einmaligen Konvertierung zu vertrauen, sammeln sie Belege über Erkundung, Regelprüfung, Implementierung, Datentests und parallele Ausführung hinweg.

Das ist die zentrale Aussage der Veranstaltung. Google präsentiert Modernisierung als kontrolliertes System von Nachweisen, nicht als einzelnes Transformationsprojekt.

Warum Mainframe-Modernisierung keine Aufgabe der Codeübersetzung ist

Eine syntaktisch korrekte Konvertierung kann dennoch das falsche Geschäftssystem reproduzieren.

Große Mainframe-Bestände verhalten sich selten wie ordentlich strukturierte Sammlungen unabhängiger Anwendungen. Ein nächtlicher Batch-Job kann Daten aktualisieren, die am nächsten Morgen von einer Online-Transaktion genutzt werden. Ein gemeinsames Copybook kann Datensätze prägen, die in mehreren Geschäftsbereichen verwendet werden.

Einige Abhängigkeiten liegen im Code. Andere befinden sich in Schedulern, Datenbankkonventionen, Betriebs-Runbooks oder im Wissen von Mitarbeitenden, die eine Arbeitslast seit Jahrzehnten betreuen.

Das macht direkte Codeübersetzung zu einem unvollständigen Modell. Ein Sprachmodell kann plausiblen Java-Code aus einer COBOL-Routine erzeugen und dennoch übersehen, warum diese Routine nach einem anderen Job ausgeführt wird. Es kann auch Logik bewahren, die das Unternehmen nicht mehr benötigt.

Das gegenteilige Risiko ist ebenso gravierend. Ein generierter Ersatz könnte Verhalten vereinfachen, das redundant wirkt, aber eine seltene regulatorische Ausnahme behandelt. Dieser Fehler könnte erst bei einer ungewöhnlichen Transaktion oder einem Quartalsendprozess sichtbar werden.

Googles bewertungsorientiertes Design versucht, diese Beziehungen überprüfbar zu machen. Laut der Dokumentation erzeugt das Tool Aufrufbäume, Abhängigkeitsberichte, Zusammenfassungen von Geschäftsregeln und vorgeschlagene migrierbare Einheiten.

Das Bewertungssystem unterstützt zudem einen MCP-Server, über den KI-Agenten Bewertungsdaten mittels des Model Context Protocol abfragen können. MCP ist eine Standardschnittstelle, die Modelle mit externen Tools und strukturiertem Kontext verbindet.

Diese Architektur gibt Gemini mehr als einen Ordner mit Quelldateien. Es kann mit ermittelten Beziehungen, geprüften Spezifikationen und Geschäftsregeln arbeiten, die an eine bestimmte Anwendungsdomäne gebunden sind.

Ein umfassenderer Kontext garantiert jedoch keine präzise Interpretation. Generierte Spezifikationen können Sonderfälle auslassen, und statische Analyse kann nicht jede Abhängigkeit beobachten, die durch Laufzeitkonfigurationen oder externe Betriebsabläufe entsteht.

Die menschliche Prüfung bleibt daher Teil des Mechanismus. Fachexperten müssen entscheiden, ob eine vorgeschlagene Geschäftsregel gültig, veraltet, unvollständig oder missverstanden ist.

Das schafft eine praktische Einschränkung für Unternehmen, die mit Personalfluktuation konfrontiert sind. Der Workflow benötigt erfahrene Betriebsmitarbeitende gerade dann am dringendsten, wenn deren Wissen am schwersten zu ersetzen ist. KI kann ihre Prüfung organisieren, aber kein fehlendes institutionelles Wissen nachträglich bereitstellen.

Der Google-Ansatz verändert auch den Zweck von Legacy-Code. Anstatt jede Anweisung als bewahrenswert zu behandeln, können Teams den Bestand als Beleg für beabsichtigtes Geschäftsverhalten betrachten.

Diese Unterscheidung unterstützt Cloud-native Neugestaltung. Ein Transaktionsmonitor benötigt kein wörtliches Gegenstück, wenn ein Managed Service dieselbe geprüfte Anforderung erfüllen kann. Ein Batch-Prozess kann zu einem ereignisgesteuerten Dienst werden, wenn Zeit- und Konsistenzanforderungen dies zulassen.

Eine Neugestaltung erweitert jedoch den Validierungsaufwand. Je weiter sich die Zielarchitektur von der ursprünglichen Implementierung entfernt, desto weniger nützlich wird ein zeilenweiser Vergleich.

Teams müssen Ergebnisse, Nebenwirkungen, Timing, Datenintegrität und Fehlerbehebung vergleichen. Deshalb ist Dual Run in Googles Darstellung zentral und nicht optional.

Das Versprechen ist keine perfekte Übersetzung. Es ist eine nachvollziehbare Kette von Legacy-Nachweisen über geprüfte Regeln und generierte Implementierung bis hin zu gemessener Gleichwertigkeit.

Der eigentliche Wettbewerb lautet iterative Modernisierung gegen den Big Bang

Googles stärkstes Argument ist organisatorischer Natur: Kleinere Migrationseinheiten begrenzen die Folgen von Unsicherheit.

Eine Big-Bang-Migration bündelt viele Annahmen in einer einzigen Umschaltung. Teams müssen Abhängigkeiten verstehen, Code transformieren, Daten übertragen, Schnittstellen testen, Betreiber schulen und Rollback-Verfahren über einen breiten Umfang hinweg vorbereiten.

Eine falsch verstandene Abhängigkeit kann das gesamte Programm verzögern. Schlimmer noch: Ein Defekt kann erst die Produktion erreichen, nachdem die ursprüngliche Umgebung nur noch schwer wiederherzustellen ist.

Iterative Modernisierung reduziert diesen Schadensradius. Teams können eine abgegrenzte Domäne auswählen, ihre Beziehungen dokumentieren, eine Zielimplementierung entwickeln und sie validieren, während benachbarte Arbeitslasten unverändert bleiben.

Das macht Modernisierung nicht einfach. Es verändert, wie sich Fehler auswirken.

Ein Problem, das während einer Migrationseinheit entdeckt wird, kann die Bewertungsregeln für die nächste Einheit verbessern. Abweichungen in Tests können undokumentiertes Verhalten aufdecken, bevor das Unternehmen sich auf eine umfassendere Umschaltung festlegt.

Dual Run bildet die operative Brücke. Googles früheres Modell für parallele Tests behält den Mainframe als Primärsystem bei, während eine Cloud-Kopie dieselbe Arbeitslast als Sekundärsystem ausführt.

Die Cloud-Ausgabe kann anschließend mit dem etablierten Ergebnis verglichen werden. Wiederholte Unterschiede legen Defekte in transformierter Logik, Datenkonvertierung oder Umgebungsannahmen offen.

Das ist insbesondere für transaktionsintensive Systeme relevant. Ein Unit-Test kann eine bekannte Berechnung verifizieren, aber nicht jede Interaktion zwischen realen Eingabemustern, Planungsbedingungen und nachgelagerten Integrationen reproduzieren.

Die parallele Ausführung liefert breitere Nachweise, ohne dem neuen System sofort Produktionsautorität zu übertragen. Teams können Akzeptanzschwellen festlegen, Unterschiede untersuchen und Tests wiederholen, bevor sie die Verantwortung übergeben.

Der Kompromiss ist eine verlängerte Koexistenz. Der Betrieb zweier Umgebungen erfordert Synchronisierung, Monitoring, Kontrollen gegen doppelte Verarbeitung und eine klare Entscheidung darüber, welches System für jede Ausgabe zuständig ist.

Auch die Kosten können sich während des Übergangs überschneiden. Google beseitigt diese betriebliche Belastung nicht. Das Unternehmen argumentiert, dass diese Belastung einen sichereren Weg weg von einem Alles-oder-nichts-Ereignis ermöglicht.

Das inkrementelle Modell wirft zudem Governance-Fragen auf. Teams benötigen Regeln für die Auswahl von Migrationseinheiten und für die Entscheidung, wann eine Anwendung eine ausreichende Gleichwertigkeit nachgewiesen hat.

Sie müssen verfolgen, welche Geschäftsregeln akzeptiert wurden, wer sie genehmigt hat, welche Testnachweise sie stützen und was sich nach der Validierung geändert hat. Ohne diese Aufzeichnungen kann iterative Arbeit einen fragmentierten hybriden Bestand schaffen.

Architekturdisziplin ist hier entscheidend. Eine Abfolge isolierter Cloud-Projekte kann Mainframe-Komplexität durch neue Dienste, Queues, Datenbanken und undokumentierte Schnittstellen reproduzieren.

Googles Tools können Artefakte abbilden und generieren, doch ein Unternehmen benötigt weiterhin eine kohärente Zielarchitektur. Es braucht außerdem einen Stilllegungsplan für jede Mainframe-Komponente, die durch die Cloud ersetzt wird.

Der Ansatz gelingt, wenn Iteration zu kumulativer Vereinfachung führt. Er scheitert, wenn jede migrierte Einheit eine weitere permanente Brücke zurück zum Legacy-Bestand schafft.

Deshalb lautet der Wettbewerb nicht Geschwindigkeit gegen Vorsicht. Ein überstürzter Big Bang kann spektakulär scheitern, während ein endloses inkrementelles Programm leise scheitern kann.

Die maßgebliche Kennzahl ist die abgeschlossene geschäftliche Fähigkeit. Jede Migrationseinheit sollte einen validierten Produktionsbetrieb erreichen und die entsprechende Verantwortung des Altsystems ablösen.

Google Cloud trifft IBM und AWS unter anderen Voraussetzungen

Alle drei Anbieter setzen inzwischen KI ein, unterscheiden sich jedoch darin, wo die modernisierte Workload laufen sollte und wie Gleichwertigkeit nachgewiesen wird.

IBMs Position beginnt mit dem fortbestehenden Wert des Mainframes. Sein watsonx Code Assistant for Z unterstützt bei Erkundung, Erklärung, Refactoring, Codegenerierung, Optimierung und Transformation, während IBM Z eine wichtige Laufzeitumgebung bleibt.

IBM zufolge kann sein Assistant COBOL, PL/I, REXX, Assembler und JCL erklären. Er kann ausgewählte Programme auch in modulare Services umgestalten oder COBOL in objektorientiertes Java transformieren.

Die KI-Modernisierungstools des Unternehmens umfassen automatisierte Unit-Tests für semantische Gleichwertigkeit. Damit ist gemeint, dass neuer Code dasselbe beabsichtigte Verhalten wie das Original liefern sollte, selbst wenn sich seine Struktur verändert.

Dieser Weg kann für Unternehmen geeignet sein, die bessere Entwicklungspraktiken wünschen, ohne jede Workload auf eine Hyperscale-Cloud festzulegen. Er ermöglicht Teams außerdem, rund um einen Mainframe zu modernisieren, statt die Plattform als Ablaufdatum zu behandeln.

AWS vertritt eine Position, die Googles Cloud-Ziel näherkommt, betont derzeit jedoch agentische Ausführung und Nachvollziehbarkeit. AWS Transform for mainframe deckt Bewertung, Extraktion von Geschäftsregeln, Anforderungen, Codegenerierung, Tests und Bereitstellung ab.

AWS zufolge lässt sich jedes generierte Ergebnis über die Anforderungen bis zum ursprünglichen Quellcode zurückverfolgen. Sein agentischer Workflow integriert sich zudem über offene Protokolle mit Coding Agents wie Kiro und bestehenden Entwicklungsumgebungen.

Diese Nachvollziehbarkeit zielt auf dieselbe Vertrauenslücke wie Googles Dual Run. Sie bietet Prüfern einen Auditpfad, der zeigt, woher eine Anforderung oder generierte Komponente stammt.

Googles Differenzierung liegt in der Verbindung von kontextbezogener Bewertung mit Datenkonvertierung und paralleler Validierung auf Workload-Ebene. Gemini unterstützt beim Verstehen und Generieren, während Dual Run das Verhalten mit dem führenden Betriebssystem abgleicht.

Dabei handelt es sich nicht um klar getrennte Produktkategorien. IBM bietet ebenfalls Erkundung und Tests an. AWS beansprucht ebenfalls automatisierte Validierung funktionaler Gleichwertigkeit. Jeder Anbieter erweitert sein Angebot über den gesamten Lebenszyklus hinweg.

Der Wettbewerbsdruck wird sich daher auf Implementierungsnachweise verlagern. Käufer müssen wissen, welche Sprachen, Scheduler, Datenbanken, Transaktionssysteme und Datenformate jeder Workflow in ihrer Systemlandschaft verarbeitet.

Sie müssen zudem Produktfähigkeiten von der Servicebereitstellung unterscheiden. Mainframe-Programme beziehen häufig Systemintegratoren, interne Experten, Anbieterspezialisten und jahrelange Anwendungshistorie ein.

Kein Modell arbeitet unabhängig von dieser Bereitstellungsstruktur. KI kann manuelle Analysen reduzieren, Spezifikationen entwerfen und Code generieren, doch Integrationsentscheidungen bleiben für jede Umgebung spezifisch.

Vendor Lock-in ist ein weiterer Gesichtspunkt. Eine generierte Architektur kann die Datenbanken, Compute-Plattformen, Monitoring-Systeme und KI-Dienste eines Anbieters bevorzugen.

Diese Ausrichtung kann die Bereitstellung vereinfachen. Sie kann jedoch auch die Wechselkosten erhöhen, wenn ein Unternehmen später seine Cloud-Strategie ändert oder Workloads über mehrere Umgebungen hinweg beibehält.

Unternehmen sollten daher Artefakte bewerten, nicht nur Demonstrationen. Exportierbare Regeln, lesbare Spezifikationen, portable Tests und nachvollziehbare Freigaben sind über die erste Transformation hinaus wichtig.

Der Markt bewegt sich auf KI-gestützte Modernisierung zu. Der ungelöste Wettbewerb betrifft die Frage, wo Menschen die Arbeit überprüfen, wie Anbieter Gleichwertigkeit messen und welche Plattform das Ergebnis besitzt.

Was der KI-Workflow von Google Cloud weiterhin nicht garantieren kann

Der Workflow reduziert bestimmte Migrationsrisiken, belegt jedoch nicht, dass generierte Geschäftsregeln oder Zielcode korrekt sind.

Die erste Unsicherheit tritt bei der Erkundung auf. Statische Analyse kann Quellcodebeziehungen und deklarierte Aufrufe identifizieren, doch dynamisches Verhalten kann von Laufzeitwerten, Bedienerentscheidungen oder externen Systemen abhängen.

Eine KI-generierte Zusammenfassung kann auch sicherer klingen, als die zugrunde liegenden Belege es zulassen. Prüfer könnten einer klaren Erklärung zustimmen, weil sie gut lesbar ist, obwohl sie einen seltenen Verzweigungsfall auslässt.

Dadurch entsteht Automatisierungsbias, also übermäßiges Vertrauen in die Empfehlung eines Systems. Eine ausgearbeitete Spezifikation kann dieses Risiko erhöhen, weil sie die in der zugrunde liegenden Systemlandschaft vorhandene Mehrdeutigkeit verdeckt.

Googles eigener Workflow behält einen Prüfschritt für extrahierte Regeln bei. Unternehmen sollten diesen Schritt als Kontrollmechanismus behandeln, nicht als administrativen Kontrollpunkt.

Die Prüfung benötigt benannte Verantwortliche, verknüpfte Belege und explizite Entscheidungen. Eine Regel sollte als akzeptiert, abgelehnt, überarbeitet oder ungeklärt markiert werden, bevor sie generierten Code steuert.

Sicherheit fügt eine weitere Ebene hinzu. Google erklärt, dass das Mainframe Assessment Tool gesammelte Bewertungsdaten innerhalb seiner bereitgestellten virtuellen Maschine hält. Die Dokumentation besagt außerdem, dass Quellcode auf die Gemini Enterprise Agent Platform hochgeladen wird.

Dieselbe Dokumentation erklärt, dass das Modell nicht mit Informationen aus diesem Code angereichert wird. Organisationen müssen dennoch regionale Kontrollen, Zugriffsrichtlinien, Aufbewahrungsverhalten und vertragliche Anforderungen für ihre Workloads prüfen.

Auch Tests haben Grenzen. Dual Run kann Unterschiede zwischen beobachteten Ausgaben erkennen, doch Gleichwertigkeit hängt von Abdeckung und Qualität des Vergleichs ab.

Wenn beide Umgebungen nur gewöhnliche Transaktionen erhalten, bleiben seltene Fälle ungetestet. Wenn die Vergleichslogik Timing, Reihenfolge oder nachgelagerte Nebenwirkungen ignoriert, können zwei Ausgaben gleich erscheinen, obwohl sich die Systeme unterschiedlich verhalten.

Parallele Tests können zudem fehlerhaftes Legacy-Verhalten reproduzieren. Der Abgleich mit dem Mainframe ist während der Migration nützlich, beweist jedoch nicht, dass jede übernommene Regel wünschenswert ist oder aktuellen Richtlinien entspricht.

Teams müssen zwei Fragen trennen. Verhält sich die Cloud-Implementierung wie das Original, und sollte das ursprüngliche Verhalten erhalten bleiben?

Die zweite Frage erfordert geschäftliche, rechtliche, sicherheitsbezogene und operative Beurteilung. Codeanalyse allein kann sie nicht beantworten.

Auch Leistungsversprechen benötigen produktionsnahe Nachweise. Ein generierter Service kann Funktionstests bestehen und dennoch bei Spitzenvolumen inakzeptable Latenz, Infrastrukturverbrauch oder Datenbankkonflikte verursachen.

Die operative Wiederherstellung verdient dieselbe Aufmerksamkeit. Teams sollten Wiederholungsversuche, Teilfehler, verzögerte Nachrichten, doppelte Transaktionen und Rollback-Verfahren testen, bevor sie Verantwortung übertragen.

Schließlich kann der Workflow den Abschluss eines Programms nicht garantieren. Ein Unternehmen kann ausgezeichnete Bewertungen und Prototypen erstellen, ohne auch nur eine Mainframe-Workload stillzulegen.

Erfolg erfordert Ausstiegskriterien für jede Migrationseinheit. Diese Kriterien sollten funktionale Nachweise, operative Bereitschaft, Datenabgleich, Sicherheitsfreigabe, Kostenerwartungen und die tatsächliche Stilllegung von Altsystemen abdecken.

Googles Strategie ist sicherer, weil sie Unsicherheit früher sichtbar macht. Sie ist nicht allein deshalb sicher, weil KI beteiligt ist.

Worauf zu achten ist, wenn Google Cloud von der Methode zu Nachweisen übergeht

Der nächste Test besteht darin, ob die gestufte Methode wiederholbare Produktivumstellungen ermöglicht – nicht darin, ob sie überzeugenderen generierten Code liefert.

Das erste Signal sind Kundennachweise, die an abgeschlossene Migrationseinheiten gebunden sind. Käufer sollten nach benannten Produktions-Workloads suchen, die parallele Tests bestanden und die Verantwortung als führendes System übernommen haben.

Eine hilfreiche Fallstudie würde Umfang, unterstützte Artefakte, entdeckte Abhängigkeiten, Validierungsdauer, Umgang mit Abweichungen und die letztlich stillgelegten Mainframe-Komponenten erläutern. Allgemeine Aussagen über schnellere Analysen sind weniger aussagekräftig.

Wiederholte Umstellungen würden Googles Argument stärken, dass der Workflow über eine sorgfältig ausgewählte Anwendung hinaus skaliert. Bewertungen ohne Stilllegung in der Produktion würden es schwächen.

Das zweite Signal ist eine tiefere Nachvollziehbarkeit über die gesamte Toolchain hinweg. Googles Release-Verlauf zeigt fortlaufende Arbeit an der Extraktion von Geschäftsregeln, MCP-Zugriff, Sprachabdeckung und der Analyse großer Systemlandschaften.

Der entscheidende Fortschritt würde jede genehmigte Regel mit Quellcodebelegen, generierten Komponenten, Tests, Vergleichsergebnissen und menschlichen Freigaben verknüpfen. Diese Kette würde die Prüfung bei Audits und der späteren Wartung erleichtern.

Sie würde Teams außerdem helfen zu erkennen, an welcher Stelle ein Fehler in den Prozess gelangt ist. Eine Abweichung könnte auf fehlerhafte Extraktion, eine geänderte Anforderung, generierten Code, konvertierte Daten oder das Validierungs-Harness zurückweisen.

Klare Nachvollziehbarkeit würde das iterative Modell stärken, weil sich Wissen über Migrationseinheiten hinweg ansammeln könnte. Fragmentierte Artefakte würden jede Einheit wie ein separates Projekt wirken lassen.

Das dritte Signal ist, wie IBM und AWS mit vergleichbaren Validierungsnachweisen reagieren. Funktionslisten überschneiden sich bereits, daher müssen Anbieter zeigen, wie ihre Methoden mit realen Abhängigkeiten und schwierigen Umstellungen umgehen.

IBM kann argumentieren, dass Modernisierung nicht die Aufgabe von IBM Z erfordert. AWS kann die Nachvollziehbarkeit vom Quellcode bis zur Ausgabe und automatisierte Tests hervorheben. Google muss beweisen, dass kontextbezogene Bewertung plus Dual Run eine bessere Risikogrenze bietet.

Dieser Wettbewerb sollte Unternehmenskäufern zugutekommen. Er verschiebt die Diskussion weg von reinen Demonstrationen der Codegenerierung hin zu Nachweisen, Governance, Portabilität und abgeschlossenen Ergebnissen.

Für Technologieführungskräfte besteht die unmittelbare Maßnahme nicht darin, eine Migration der gesamten Systemlandschaft zu genehmigen. Sie sollten einen aussagekräftigen Bereich auswählen und die vollständige Kette testen.

Der Bereich sollte reale Abhängigkeiten und geschäftliche Folgen enthalten, ohne zu einem unumkehrbaren ersten Schritt zu werden. Seine Bewertung sollte Code, Daten, Zeitpläne, Schnittstellen und operatives Wissen einbeziehen.

Teams sollten festhalten, wie viele extrahierte Regeln Korrekturen erfordern, wie oft parallele Ergebnisse voneinander abweichen und wie lange die Behebung jeder Abweichung dauert. Diese Kennzahlen zeigen mehr als das Volumen generierten Codes.

Sie sollten außerdem entscheiden, was nach einer erfolgreichen Umstellung endet. Eine Migrationseinheit ist unvollständig, wenn die ursprüngliche Workload, Lizenzlast, der operative Prozess und die Supportverantwortung allesamt bestehen bleiben.

Google Cloud bietet Unternehmen einen Weg zwischen unbefristeter Wartung und einem gefährlichen Big Bang. Dieser Weg ist glaubwürdig, weil er Modernisierung als Erkundung, Rekonstruktion und Nachweis behandelt.

Sein Wert wird davon abhängen, ob Kunden diesen Zyklus über komplexe Systemlandschaften hinweg wiederholen können, ohne ein dauerhaftes Hybrid-Labyrinth zu schaffen. Die nächsten Produktivumstellungen werden wichtiger sein als die nächste KI-generierte Demo.