Jeder Enterprise-Technologieanbieter behauptet inzwischen, KI werde Migration „lösen". Der Pitch ist überzeugend: Ein KI-Modell auf die Legacy-Codebasis in COBOL, Java 6 oder monolithischem .NET richten, und es generiert den äquivalenten Code auf einem modernen Stack. Migration in Wochen statt Jahren. Aufwandsreduktion von 80 % oder mehr.
Die Wirklichkeit ist nuancierter als dieser Pitch — aber auch interessanter, als die Skeptiker vermuten lassen. KI-gestützte Migration produziert messbare Ergebnisse auf echten Enterprise-Codebasen. Die Ergebnisse sind ungleichmäßig, die Limitierungen sind signifikant, und das fundamentale Migrationsrisiko ist nicht verschwunden. Aber die Ökonomie der Migration verändert sich tatsächlich, und DACH-Mittelstandsunternehmen müssen verstehen, was das für ihre Planung konkret bedeutet.
Was die Anbieter behaupten — und was sich verifizieren lässt
Seit 2025 sind dedizierte KI-Migrationsprodukte der großen Hyperscaler am Markt. AWS Transform, im Mai 2025 allgemein verfügbar geworden, adressiert explizit Mainframe-Workloads: Das System zerlegt monolithische COBOL-Applikationen in handhabbare Komponenten, analysiert Abhängigkeiten per Graph-Neural-Networks und generiert Java- bzw. PostgreSQL-äquivalenten Code. Microsoft hat mit dem Azure Agent Framework zur COBOL-nach-Java-Modernisierung nachgezogen. Beide Plattformen liefern erste publizierte Kundenergebnisse.
Was sich verifizieren lässt: Nomura Research Institute berichtet, dass komplexe Komponentenanalysen, die zuvor etwa einen Monat in Anspruch nahmen, mit AWS Transform auf rund eine Woche reduziert wurden. Das Implementierungshaus SourceFuse gibt an, Netzwerk-Konfigurationsaufgaben, für die bislang zwei Wochen kalkuliert wurden, in einer Stunde abzuschließen. AWS selbst publiziert eine Benchmark-Zahl von durchschnittlich viermal schnellerer Transformation im Vergleich zu manuellen Ansätzen — mit Spitzenwerten von bis zu 80-fach bei reinen VMware-Migrationsprojekten.
Diese Zahlen verdienen Respekt — und kritische Einordnung. Die Benchmark-Spitzenwerte betreffen spezifische, gut strukturierte Migrationsphasen: Planungsautomatisierung, Code-Discovery, syntaktische Übersetzung. Sie repräsentieren nicht den Gesamtprojektaufwand. Der Unterschied zwischen „Code-Porting 80 % schneller" und „Migration 80 % günstiger" ist der Fehler, den Vendor-Pitches systematisch begehen.
Wo KI strukturell stark ist
Die messbaren Produktivitätsgewinne konzentrieren sich auf einen klar definierten Aufgabentyp: mechanische, musterbasierte, repetitive Arbeit. Syntax-Übersetzung ist das deutlichste Beispiel — ein Java-6-Modul mit Struts-Patterns, das in ein Spring-Boot-Äquivalent übertragen wird, oder ein VB.NET-Batch-Prozessor, der zu einem Python-Service wird. KI-Modelle übernehmen die Übersetzungsarbeit, die traditionell den größten Block an Entwicklerstunden verbrauchte, und sie tun das mit hoher Konsistenz.
Pattern-Konvertierung folgt derselben Logik. Legacy-Codebasen sind voll von wiederholten Strukturen: Datenzugriffscode, Validierungslogik, Serialisierungsroutinen, Error-Handling. Wo ein Entwickler einen Tag damit verbringt, 20 ähnliche Datenzugriffsmethoden zu konvertieren, generiert ein KI-Modell alle 20 in Minuten — mit anschließender manueller Prüfung. Hinzu kommt die Generierung von Boilerplate: moderne Frameworks erfordern erhebliches Scaffolding, und KI erledigt Setup-Arbeit, die sich über eine große Migration summiert, zuverlässig.
Ein häufig unterschätzter Mehrwert ist die Dokumentationsextraktion. Legacy-Code hat oft spärliche Dokumentation. KI-Modelle können den Code lesen, die Intention ableiten und für die migrierte Codebasis erstmals strukturierte technische Dokumentation erzeugen. Das ist kein reiner Migrationsvorteil — es schafft ein Asset, das vorher nicht existierte.
All diese Aufgaben teilen eine gemeinsame Eigenschaft: Sie sind genau die Arbeiten, bei denen KI-Augmentierung die stärksten Ergebnisse liefert — und die von den Qualitätsrisiken am wenigsten betroffen sind, die bei anderen KI-gestützten Entwicklungsaufgaben auftreten.
Die Qualitätsfrage, die Anbieter nicht stellen
Bevor Erwartungen zu hoch gesetzt werden, lohnt ein Blick auf die strukturelle Schwäche KI-generierten Codes: nicht die funktionale Korrektheit im Moment der Generierung, sondern die langfristige Wartbarkeit.
GitClear hat in seiner 2025-Studie 211 Millionen geänderte Code-Zeilen aus dem Zeitraum 2020 bis 2024 analysiert — aus Repositories von Google, Microsoft, Meta und Enterprise-Unternehmen. Das Ergebnis ist ernüchternd: Der Anteil duplizierten Codes stieg von 8,3 % (2021) auf 12,3 % (2024). Gleichzeitig sank der Anteil der Codeänderungen, die als Refactoring klassifiziert werden können, von 25 % auf unter 10 %. 2024 war das erste Jahr, in dem neu eingeführter duplizierter Code die Refactoring-Aktivität überstieg.
Für Migrationsprojekte ist das relevant: KI generiert mehr Code schneller, aber mit höherer struktureller Redundanz. Wer auf KI-generiertem Code aufbaut, ohne konsequentes Review und Refactoring einzuplanen, akkumuliert technische Schulden bereits ab Tag eins des neuen Systems. Das ist kein Argument gegen KI-gestützte Migration — es ist ein Argument für sorgfältiges Code-Review als nicht verhandelbaren Bestandteil des Prozesses.
Was KI nicht übernimmt — und warum das entscheidend ist
Die Produktivitätsgewinne beim Code-Porting klingen groß, bis man versteht, welchen Anteil Code-Porting am Gesamtaufwand einer Enterprise-Migration ausmacht. Wenn Code-Porting 25–30 % des Gesamtprojekts repräsentiert und KI diesen Anteil um 40 % reduziert, ergibt sich eine Gesamteinsparung von 10–12 %. Das ist bedeutsam — es ist nicht transformativ.
Die restlichen 70–75 % verteilen sich auf Aufgaben, die KI strukturell nicht übernimmt.
Testing und Validierung ist die größte davon. Bei Enterprise-Migrationen macht Testing typischerweise 40–50 % des Gesamtaufwands aus. KI kann Test-Scaffolding generieren, aber sie kann nicht validieren, ob das migrierte System sich in Ihrem spezifischen Geschäftskontext korrekt verhält. Berechnet der Schadenbearbeitungs-Workflow noch den richtigen Reservebetrag für einen Teilhaftungsfall? Wendet das Order-Management noch korrekte Rabattstaffeln für Rahmenvertragskunden an? Das sind domänenspezifische Validierungen, die menschliches Urteilsvermögen und Geschäftswissen erfordern und die durch schnellere Codegenerierung nicht kürzer werden. Im Gegenteil: KI-generierter Code sollte rigoroser getestet werden, weil der Entwickler beim Review weniger implizites Wissen über die Implementierungsentscheidungen mitbringt als beim selbst geschriebenen Code.
Integrationsvalidierung bleibt vollständig manuell. Legacy-Systeme existieren nicht isoliert — sie verbinden sich mit anderen Systemen über APIs, Datenbanklinks, Dateiaustausch und Message Queues. Den Code zu migrieren migriert nicht die Integrationen. Jede vor- und nachgelagerte Verbindung muss neu validiert, viele müssen neu gebaut werden. Ein Versicherungs-Schadensystem, das über eine proprietäre Schnittstelle mit einer Rückversicherungsplattform kommuniziert, bekommt keine kostenlose Integrationsmigration, nur weil der Schadencode portiert wurde.
Datenabstimmung ist daten- und domänenspezifisch. KI-Tools können bei Schema-Mapping helfen, aber die Abstimmung selbst — was die Daten in geschäftlicher Hinsicht bedeuten, welche Inkonsistenzen auflösbar sind und welche nicht — erfordert tiefes Domänenwissen.
Berechtigungs- und Sicherheitsredesign ist konzeptionell, nicht mechanisch. Legacy-Systeme haben Berechtigungsmodelle, die über Jahrzehnte gewachsen sind: rollenbasierter Zugriff gemischt mit individuellen Überschreibungen, implizite Berechtigungen tief in der Business-Logik, Sicherheitschecks über die gesamte Codebasis verstreut. Die neue Plattform braucht eine kohärente Sicherheitsarchitektur — und um die zu bauen, muss man die Intention hinter den Legacy-Berechtigungen verstehen, nicht nur ihre Implementierung lesen.
Produktionsstabilisierung schließlich ist die gefährlichste Phase jeder Migration. Die ersten Wochen nach dem Cutover bringen Probleme ans Licht, die keine Testumgebung entdeckt hat: Performance unter realer Last, Edge Cases in Nutzerpfaden, Dateninkonsistenzen aus subtilen Unterschieden in Gleitkomma-Präzision oder Datumsbehandlung, die erst Wochen später sichtbar werden. Diese Phase erfordert erfahrene Ingenieure mit tiefem Wissen über beide Systeme — Legacy und Modern. KI-Tools helfen hier strukturell nicht.
Was sich daraus für die Planungskalkulation ergibt
Für DACH-Mittelstandsunternehmen, die Modernisierung planen, hat das drei praktische Konsequenzen.
Migrationskosten sind keine fixe Größe mehr. Traditionelle Schätzungen gehen von konstanten Kosten pro Modul aus, adjustiert nach Komplexität. KI-gestützte Migration führt eine zeitabhängige Variable ein: Die Kosten des Code-Portings sinken, während KI-Tools reifen. Module, die warten können, sollten später im Programm eingeplant werden, wenn die Tools besser sind. Das ist die Kernüberlegung hinter der KI-Shift-Migrationsstrategie: Wenn Migrationskosten sinken, kann es bessere Gesamtergebnisse liefern, jetzt Wert zu schaffen und später zu migrieren, statt sofort zu migrieren.
Nicht auf hypothetische zukünftige Fähigkeiten wetten. Die Entwicklung der KI-Migrationstools ist positiv, aber das Verbesserungstempo ist unsicher. Ein Programm auf der Annahme zu planen, dass KI den Gesamtaufwand in zwei Jahren um 70 % reduziert, ist spekulativ. Die derzeit belegbaren Einsparungen beim Code-Porting zu nehmen und konservativ zu modellieren, ist vertretbar. Die Tools auf der eigenen Codebasis zu benchmarken, bevor sie in die Projektkalkulation einfließen, ist zwingend.
Auf dem eigenen Code benchmarken, nicht auf Vendor-Daten. Vendor-Benchmarks basieren auf spezifischen Codebasen und Tool-Versionen. Ihr Legacy-Code hat eigene Eigenschaften: Sprache, Framework, Komplexität, Domänenlogik-Dichte. Was bei einem Java-Retail-System gut funktioniert, kann bei einem COBOL-Versicherungskern versagen. Der einzige Benchmark, der zählt, ist der auf Ihren eigenen Modulen — idealerweise auf einem Modul, das Sie bereits manuell migriert haben, um eine echte Vergleichsbasis zu haben. Diese Messung quartalsmäßig zu wiederholen gibt Ihnen die organisationsspezifischen Daten, auf die Migrations-Decision-Gates sich abstützen müssen.
Leitplanken für den laufenden Einsatz
Wenn KI-Tools in einer laufenden oder geplanten Migration eingesetzt werden, sind diese Leitplanken nicht verhandelbar. Code Review nicht auslassen — KI-generierter Code muss mit derselben Sorgfalt reviewt werden wie handgeschriebener Code, mit Entwicklern, die die Business-Logik verstehen, nicht nur die Syntax prüfen. Den Testumfang nicht reduzieren, weil Code schneller generiert wird — das ist genau verkehrt herum, und die GitClear-Daten zur steigenden Code-Duplikation liefern den strukturellen Grund dafür. Manuelle Migrationsfähigkeit beibehalten: Mancher Legacy-Code ist zu idiosynkratisch oder zu eng gekoppelt für automatisiertes Porting, und kein Programm sollte auf 100 % KI-Abdeckung setzen. Und alle sechs Monate ein Decision Gate einplanen, das bewertet, ob die tatsächlichen Aufwandseinsparungen mit den Planungsannahmen übereinstimmen.
Die nüchterne Einschätzung
KI-gestützte Migration reduziert Code-Porting-Kosten schneller als erwartet — das ist die gute Nachricht, und sie ist tatsächlich signifikant. Für eine Migration, bei der Code-Porting 25–30 % des Gesamtaufwands ausmacht, bedeutet eine substanzielle Reduktion dieses Anteils eine echte, messbare Gesamteinsparung. Das verändert die Planungskalkulation.
Es eliminiert nicht das fundamentale Enterprise-Migrationsrisiko. Testing, Integration, Datenmigration, Sicherheit und Stabilisierung repräsentieren zusammen den Großteil des Gesamtaufwands — und diese Aufgaben werden nicht im gleichen Tempo günstiger. Manche sind von Natur aus irreduzibel, weil sie Geschäftsurteilsvermögen, Domänenwissen und organisatorische Koordination erfordern, die kein Tool automatisieren kann.
Das Narrativ „KI löst Migration" ist Vendor-Marketing. Die Wirklichkeit — KI reduziert eine signifikante Komponente des Migrationsaufwands und wird das im Lauf der Zeit weiter tun — ist für DACH-Mittelstandsunternehmen trotzdem interessant genug, um die Planungsannahmen jetzt zu aktualisieren.
Ein Fit Call liefert eine ehrliche Einschätzung, welche Teile Ihres Legacy-Portfolios von KI-gestütztem Porting heute bereits profitieren — und wo der Aufwand trotzdem konservativ kalkuliert werden muss.
Quellen: GitClear, „AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones," gitclear.com/ai_assistant_code_quality_2025_research (2025); AWS, „AWS Transform Generally Available," aws.amazon.com/blogs/migration-and-modernization/aws-transform-generally-available/ (2025).