Migration Planning

Zuletzt aktualisiert: 19. August 2026

Agentic Legacy Migration: Wissen erschließen, gezielter modernisieren

Bei vielen Legacy-Systemen ist die Business Logic nur noch schwer zugänglich. Sie steckt in altem Code, Datenflüssen und im Wissen weniger Systemkenner. AI kann Business Logic und Abhängigkeiten wieder sichtbar machen. So wird aus einer vermeintlichen Vollmigration die Entscheidung, was bleibt, ersetzt oder wirklich neu gebaut werden muss.

Erst Business Logic verstehen, dann Technologie wählen

Viele Unternehmen betreiben geschäftskritische Systeme, die nur noch in Teilen verstanden werden. Das betrifft Mainframes ebenso wie alte Java- und .NET-Anwendungen, proprietäre Plattformen, gewachsene Datenbanken und schlecht dokumentierte Integrationen. Jede Änderung beginnt deshalb mit technischer Archäologie.

COBOL-zu-Java oder Mainframe-zu-Cloud legt bereits eine technische Behandlung fest. Oft ist zu diesem Zeitpunkt noch unklar, welcher fachliche Vorgang erhalten werden muss, welches alte Verhalten entfallen kann und welcher Teil besser durch Standardsoftware ersetzt wird. Ohne dieses Wissen übersetzt das Unternehmen den Bestand, bevor es entschieden hat, was davon in die Zukunft gehört.

Agents erschließen Business Logic und Abhängigkeiten

Microsofts Legacy Modernization Agents zeigen am COBOL-Beispiel, wie AI Code untersucht, Abhängigkeiten verfolgt und mögliche Business Logic dokumentiert. Ein AI-Wiki wie DeepWiki-Open macht die Ergebnisse anschließend durchsuchbar, verlinkt Erklärungen mit dem Code und erlaubt Fragen an das System.

Die daraus entstehende Wissensbasis verbindet Business Logic und Abhängigkeiten mit den Stellen im Code, an denen sie umgesetzt sind. Teams können vor einer Änderung betroffene Prozesse und Schnittstellen finden, Requirements aus dem beobachteten Verhalten ableiten und neues Personal einarbeiten, ohne sich allein auf mündlich überliefertes Wissen zu verlassen.[1][2][3][4]

Ein System, mehrere Migrationswege

Die bekannten R-Modelle von AWS und Microsoft ordnen jeder Anwendung einen Weg wie Retain, Replatform, Replace, Rebuild oder Retire zu. In gewachsenen Systemen muss diese Entscheidung oft feiner getroffen werden. Einzelne fachliche Abläufe wie Auftragsbearbeitung, Abrechnung oder Archivierung können zusammen mit ihrem Code, ihren Daten und Schnittstellen unterschiedliche Wege nehmen.

Ein Beispiel ist ein noch nicht abgelöster Mainframe. Retain bedeutet dort nur, einen verstandenen Teil befristet weiterzubetreiben, während Abhängigkeiten gelöst und sein Nachfolger vorbereitet werden. Agentic Legacy Migration kann den Umfang des Neubaus reduzieren. Sie ersetzt jedoch keinen verbindlichen Ausstiegsplan für eine langfristig nicht mehr tragfähige Plattform.[5][6]

Aus Systemwissen werden Migrationspakete

Wohin migrieren? Bet on the web!

Über Zielstacks wird gerne wie über Glaubensfragen gestritten. Für eine langfristig tragfähige Planung ist die Frage nüchterner: Wie viele Sprachen, Datenbanken und Betriebsmodelle soll das Unternehmen über Jahre finanzieren? Ein Ansatz ist, TypeScript und PostgreSQL als Default für neue Geschäftsanwendungen zu setzen. Beide decken den typischen Bedarf ab und haben große Ökosysteme. Das senkt die Zahl der Technologien, die Teams beherrschen und die das Unternehmen absichern und betreiben muss.

Mit TypeScript lassen sich Web-, Mobile- und Desktop-Anwendungen sowie serverseitige Logik entwickeln. PostgreSQL ist primär eine Datenbank. Sein Erweiterungsökosystem macht daraus für viele Anwendungen auch eine Plattform für Suche, Queues, Event Streams, Vektoren und Jobs. Dadurch entfallen oft eigene Message Broker oder Vektordatenbanken. Spezialdienste sind nur sinnvoll, wenn die Anforderungen über diese Fähigkeiten hinausgehen, was bei den meisten Geschäftsanwendungen die Ausnahme ist.[7][8][9][10]

Agentic Legacy Migration klärt Umfang, Funktionen und Risiken

Für jedes Migrationspaket dokumentiert Agentic Legacy Migration den vorgesehenen Weg: vorübergehend weiterbetreiben, auf eine andere Plattform verlagern, durch Standardsoftware ersetzen, neu bauen oder stilllegen. Dazu gehören die betroffenen Komponenten und Daten, die zu erhaltenden Funktionen und die offenen Risiken.

Weil Funktionen, Abhängigkeiten und Risiken je Migrationspaket dokumentiert sind, kann das Team konkrete Abnahmekriterien und Abbruchpunkte festlegen. Dadurch werden Umfang, Kosten und Risiken der Modernisierung früher planbar.