Migrationstools, KI-Unterstützung und Roadmap

Migrationstools, KI-Unterstützung und Roadmap

0:00 Letztes Modul. Wir haben eine Anwendung migriert — jetzt geht es um die anderen zwanzig. Dafür gibt es Werkzeuge, und es gibt Coding Agents, die repetitive Änderungen übernehmen können. Beide nehmen Ihnen Wiederholung ab. Was sie nicht abnehmen, ist die Verantwortung für das Ergebnis. Dieses Modul zeigt, was die Werkzeuge leisten, was der Forschungsstand über automatisierte Migrationen sagt, und wie Sie daraus eine Roadmap bauen, die auch ein Nein zulässt.

Migrationstools, KI-Unterstützung und Roadmap

0:28 Das Abschlussmodul. Wir sortieren die verfügbaren Werkzeuge nach ihrer Aufgabe, ordnen den Einsatz von Coding Agents nüchtern ein und stellen am Ende die Entscheidungsvorlage auf, mit der Sie aus diesem Seminar herausgehen. Wenn Sie heute nur eine Sache mitnehmen, dann bitte diese Vorlage — sie ist der Unterschied zwischen einer Erkenntnis und einer Entscheidung.

Werkzeuge für die Umstellung

0:48 Beginnen wir mit den Werkzeugen. Es gibt vier relevante, und sie tun jeweils etwas anderes — das wird regelmäßig verwechselt. Der Migrationsleitfaden von Quarkus nennt zwei mögliche Ziele: die Quarkus-nativen APIs oder die Kompatibilitätserweiterungen. Beides ist ausdrücklich zulässig — Sie müssen sich also nicht rechtfertigen, wenn Sie bei der Kompatibilitätsstufe stehenbleiben, solange das eine bewusste Entscheidung ist.

1:14 Für den Weg dorthin gibt es mehrere Werkzeuge, die unterschiedliche Teile abdecken. Und das ist der Punkt, der zählt: Keines ersetzt die anderen, und keines deckt den gesamten Weg ab. Und eine Warnung vorweg: Kein Werkzeug in dieser Liste deckt den gesamten Weg ab. Wer eines davon als Komplettlösung einplant, plant eine Enttäuschung ein — und zwar meist erst nach der Hälfte der Strecke.

1:37 Vier Werkzeuge, vier Aufgaben. Die erste Zeile ist Analyse: Sie erfahren, was in Ihrem Bestand steckt. Die zweite ist Transformation nach Rezept — deterministisch und wiederholbar, das ist der große Vorteil. Die dritte hebt ein bestehendes Quarkus-Projekt auf einen neueren Stand; das ist die Zeile, die Sie nach der Migration dauerhaft brauchen werden.

1:58 Und die vierte verbindet Analyse mit Vorschlägen in der Entwicklungsumgebung. Der häufigste Fehler ist, ein Analysewerkzeug für ein Transformationswerkzeug zu halten und dann enttäuscht zu sein. Vier Punkte, und der zweite ist der wichtigste, weil er aus der Dokumentation selbst stammt: Nur ein Teil der Migration wird automatisiert.

2:18 Das ist eine erfreulich ehrliche Aussage, und sie sollte Ihre Erwartung setzen. Die anderen drei Punkte sind Arbeitsdisziplin: eigener Zweig vor dem Lauf, Ausgabe und Diff danach prüfen, dann Build und Tests. Wer diese Reihenfolge einhält, hat ein sehr nützliches Werkzeug. Wer sie abkürzt, hat einen großen Commit, den niemand mehr nachvollziehen kann.

2:40 Der erste Punkt ist der Kern dieses Kapitels: Das Ergebnis eines Werkzeuglaufs wird ungeprüft übernommen. Der zweite ist eine Arbeitsweise, die sich rächt: kein eigener Zweig, kein Rückweg. Der dritte ist die eben erwähnte Verwechslung von Analyse und Transformation. Und der vierte ist die Voraussetzung, die alle Werkzeuge stillschweigend annehmen: Rezepte laufen über Code, für den es Tests gibt.

3:04 Ohne Tests ist automatisierte Transformation kein Werkzeug, sondern ein Glücksspiel mit großem Einsatz.

Coding Agents kontrolliert einsetzen

3:11 Damit zum Thema, das derzeit die größte Erwartung trägt: Können Coding Agents eine Migration übernehmen? Quarkus stellt für Coding Agents eigene Migration Skills bereit — den Leitfaden also in einer Form, die ein Agent lesen kann. Damit lassen sich repetitive Änderungen vorbereiten, und das ist ein echter Nutzen. Der Rest des Satzes ist genauso wichtig: Die fachliche Prüfung bleibt beim Team.

3:35 Das Bild: Ein Agent ist ein sehr schneller Werkstudent mit perfektem Gedächtnis und ohne Verantwortungsgefühl. Sie würden ihm auch nicht ungelesen einen Produktivzweig anvertrauen. Hier hilft ein Blick auf Zahlen statt auf Eindrücke. Im Benchmark ScarfBench, veröffentlicht 2026, erreichte der stärkste untersuchte Agent bei vollständigen Enterprise-Java-Migrationen eine aggregierte Testpassrate von gut zwölf Prozent; genau eine von 204 Aufgaben war vollständig verhaltensäquivalent.

4:04 Diese Zahlen sind nicht direkt auf Ihr Projekt übertragbar — jeder Benchmark hat seine Eigenheiten, und die Werkzeuge entwickeln sich schnell. Aber sie begründen sehr konkret, warum Build-, Test- und Review-Gates hier nicht verhandelbar sind. Die linke Spalte ist der sinnvolle Einsatzbereich: wiederkehrende Änderungen, erste Analyse, Entwürfe.

4:24 Alles Dinge, bei denen ein Fehler sofort auffällt und billig zu korrigieren ist. Die rechte Spalte ist die Grenze, und sie hat ein gemeinsames Merkmal: Dort geht es um Verantwortung, nicht um Arbeit. Fachliche Entscheidungen, der Nachweis von Verhaltensgleichheit, sicherheitsrelevante Zusicherungen, die Abnahme. Diese vier lassen sich nicht delegieren — nicht an ein Werkzeug und übrigens auch nicht an einen Dienstleister.

4:50 Der erste Punkt ist der praktisch häufigste: Ein Agent ändert breit, und das Review betrachtet nur die Zusammenfassung — damit ist das Review eine Formalie. Der zweite ist ein Zirkelschluss, der erstaunlich oft übersehen wird: Generierte Tests prüfen generierten Code und bestätigen damit vor allem sich selbst. Der dritte ist ein Planungsfehler: Der Zeitgewinn wird eingeplant, bevor er nachgewiesen ist.

5:12 Und der vierte ist der gefährlichste: Fehlende Tests werden durch Vertrauen in die Automatik ersetzt — also genau dort gespart, wo die Automatik ihre Voraussetzung hat.

Roadmap und Quality Gates

5:23 Bleibt der Blick nach vorn. Wie kommt man von einer migrierten Anwendung zu einem Plan für die übrigen? Eine Migrationsroadmap benennt vier Dinge: den Piloten, die Reihenfolge der weiteren Dienste, die Gates, die jeder Schritt bestehen muss, und den Zeitpunkt, an dem neu entschieden wird. Und dann kommt der Satz, auf den es ankommt: Die möglichen Entscheidungen sind Go, Pause und Stop — alle drei müssen zulässig sein.

5:47 Eine Roadmap, in der nur Go vorgesehen ist, ist keine Planung, sondern eine Ankündigung. Und Ankündigungen halten der Realität selten stand. Fünf Schritte. Der Pilot soll repräsentativ, überschaubar und getestet sein — alle drei Eigenschaften, nicht zwei davon. Die Gates kennen Sie bereits aus der Abnahmeliste des letzten Moduls. Der Aufwand wird aus dem Piloten hochgerechnet, nicht geschätzt; deshalb war das Mitschreiben dort so wichtig.

6:14 Und der fünfte Schritt ist der, der Haltung verlangt: Kriterien vorher aufschreiben. Die Fußnote sagt, warum sich das lohnt — ein Stop nach dem Piloten ist ein gültiges Ergebnis und spart mehr, als er kostet. Vier Muster, und sie treten meist gemeinsam auf. Der Pilot wird nach Bequemlichkeit gewählt und trägt keine Aussage.

6:34 Die Gates werden weich, sobald der erste Termin drückt — was sie faktisch abschafft, denn ein Gate, das man öffnen kann, ist keines. Es gibt keinen Zeitpunkt, an dem abgebrochen werden dürfte. Und der vierte ist der, der in der Praxis am meisten Reibung erzeugt: Der Bestand wird weiterentwickelt, während migriert wird. Dafür braucht es eine Absprache, keine Hoffnung.

6:57 Der erste Punkt ist der Klassiker der Überforderung: alle Dienste gleichzeitig beginnen. Der zweite verfälscht jede Hochrechnung: Der Aufwand für Security und Messaging wird beim Piloten ausgeklammert — und genau dort steckt ein erheblicher Teil der Arbeit. Der dritte ist ein Ehrlichkeitsproblem: Die Entscheidungskriterien entstehen erst, wenn die Zahlen vorliegen; dann passen sie natürlich zu den Zahlen.

7:19 Und der vierte ist organisatorisch: Der Betrieb erfährt von der Umstellung beim ersten Vorfall — das ist der denkbar schlechteste Zeitpunkt für eine Einführung.

Übung

7:29 Zum Abschluss keine Programmieraufgabe, sondern die Aufgabe, mit der Sie aus diesem Seminar herausgehen sollten. Der Hinweis ist ernst gemeint: Eine Seite genügt. Was auf einer Seite nicht begründbar ist, überzeugt auch auf zehn nicht — es verdeckt nur, dass die Begründung fehlt. Ihre Vorlage nennt Nutzen, Aufwand, Risiken, Pilot, Gates und einen Entscheidungspunkt. Und sie lässt ein Nein ausdrücklich zu.

7:54 Das ist kein Zeichen von Unentschlossenheit, sondern die Voraussetzung dafür, dass ein Ja etwas wert ist. Nennen Sie darin Nutzen, Aufwand, Risiken, Pilot, Gates und einen Entscheidungspunkt. Und formulieren Sie ausdrücklich, unter welchen Bedingungen die Antwort Nein lautet — dieser eine Absatz macht aus einer Präsentation eine Entscheidungsvorlage.

8:16 Die ersten beiden Schritte sind reines Zusammentragen — Sie haben alle Zahlen bereits erhoben. Der dritte ist der anspruchsvollste: den Nutzen benennen, der ohne Migration unerreichbar bleibt. Wenn Ihnen dazu nichts einfällt, ist das ein sehr wertvolles Ergebnis. Schritte vier und fünf bringen Struktur und Termin hinein.

8:35 Und die Fußnote ist der letzte inhaltliche Satz dieses Seminars: Die Empfehlung darf lauten, mit Spring Boot weiterzuarbeiten. Ein Seminar, das diese Antwort nicht zulässt, wäre Werbung gewesen. Vier letzte Punkte. Eine Vorlage, die Framework-Werbung wiederholt statt eigener Zahlen, überzeugt niemanden, der schon einmal eine Migration erlebt hat.

8:56 Fehlende Risiken schwächen nicht die Empfehlung, sondern die Glaubwürdigkeit. Aufwand ohne Security, Messaging und Betrieb ist systematisch zu niedrig — Sie kennen inzwischen die Größenordnung. Und ohne Überprüfungszeitpunkt bleibt eine Entscheidung stehen, auch wenn sich die Grundlage ändert. Damit sind wir am Ende: Sie haben eine Anwendung migriert, sie gemessen und können begründen, ob es sich lohnt. Vielen Dank.