Software wird legacy. Nicht, weil sie schlecht gebaut wurde, sondern weil sich die Welt um sie herum verändert. Frameworks veralten, Wissen geht mit Leuten verloren, technische Schulden häufen sich. Das passiert bei jeder langlebigen Software.
Trotzdem wird sie selten abgelöst. Das System läuft ja. Der Aufwand scheint zu gross, das Risiko zu hoch, und es gibt immer etwas Dringenderes. Also schiebt man es auf.
Mit einem klaren Prozess und AI an den richtigen Stellen lässt sich auch ein gewachsenes System ablösen. Entscheidend ist, wo man AI vertraut und wo nicht.
AI verändert die Rechnung
AI-gestützte Entwicklung macht Legacy-Ablösung realistisch. Was früher ein Jahresprojekt war, wird in Monaten machbar. Aber Tempo allein löst das Problem nicht. Ein gewachsenes System enthält tausende implizite Geschäftsregeln, die nirgends dokumentiert sind. Und AI muss geführt werden. Wer sie unkontrolliert Code generieren lässt, bekommt schnelle Ergebnisse, die bestehende Geschäftsprozesse jedoch stillschweigend brechen.
Es braucht einen klaren Prozess, der ein Legacy-System Schritt für Schritt ablöst und dabei kontrolliert, wo AI welche Rolle übernimmt.
Unser Prozess in vier Schritten
Wir gehen in vier Schritten vor. Jeder schafft die Grundlage für den nächsten.
1. Verhalten absichern
Bevor wir eine Zeile neuen Code schreiben, dokumentieren wir das bestehende Verhalten. Dafür setzen wir Golden Master Testing ein: Wir zeichnen die Eingaben und Ausgaben des laufenden Systems auf und verwenden sie als Referenz. Jeder Test sagt: So verhält sich das System heute. Wenn der neue Code dasselbe Ergebnis liefert, ist das Verhalten korrekt übernommen.
AI hilft uns beim Erstellen dieser Tests. Sie kann aus bestehendem Code Testfälle ableiten und Eingabe-Ausgabe-Paare generieren. Aber die Tests werden manuell reviewt. Da sie als Grundlage für alles Weitere dienen, wären fehlerhafte Tests schlimmer, als gar keine zu haben.
2. Schema migrieren
Ein bewährtes Datenbank-Schema ist wertvoll. Die Geschäftsdomäne bleibt dieselbe, auch wenn die Technologie wechselt. Wir migrieren das Schema auf eine neue Datenbank und lassen die Struktur so weit wie möglich stehen. Das gibt uns eine solide Basis, die bereits vieles vorgibt: Entitäten, Beziehungen, Constraints. Gleichzeitig macht ein übernommenes Schema die schrittweise Migration deutlich einfacher, weil die Datenstrukturen auf beiden Seiten zusammenpassen.
AI unterstützt bei der Analyse des Schemas und bei der Migration. Aber auch hier gilt: Ein manueller Review bleibt essenziell. Ein falsch interpretierter Foreign Key kann später ganze Geschäftsprozesse brechen.
3. Sicherheit aufsetzen
Bevor wir Funktionalität migrieren, setzen wir den Zugriffsschutz auf. Regelwerk implementiert die Berechtigungslogik direkt auf Datenzugriffsebene. Jede Query wird automatisch gefiltert, unabhängig davon, welcher Code-Teil sie absetzt.
Warum so früh? Weil Sicherheit nicht nachträglich eingebaut werden sollte. Und weil es eine Schicht ist, die wir genau studieren, Zeile für Zeile. Hier vertrauen wir AI am wenigsten. Sicherheitskritischer Code verdient maximale Sorgfalt. Wie wir dieses Schichtenmodell im Detail umsetzen, haben wir in unserem Artikel zu Regelwerk und AI beschrieben.
4. Funktionalität spec-getrieben migrieren
Wenn die Tests stehen, das Schema migriert ist und der Zugriffsschutz greift, beginnen wir mit der Migration der eigentlichen Funktionalität. Modul für Modul, in einen modernen Tech-Stack. Hier kann AI deutlich mehr Verantwortung übernehmen: Code in der neuen Technologie generieren, kleine Migrationsskripte für Datenübernahmen bauen, DevOps-Pipelines aufsetzen.
Damit das strukturiert läuft, arbeiten wir mit Spec Driven Development und nutzen dafür OpenSpec. Vor jeder Code-Generierung schreiben wir eine kurze Spezifikation, die festhält, was die Komponente leisten soll, welche Schnittstellen sie hat und welche Constraints gelten. Die AI generiert anschliessend Code, der auf dieser Vorgabe aufbaut, und wir können das Ergebnis gegen etwas Konkretes prüfen.
Gerade bei einer Legacy-Ablösung kommt das doppelt zum Tragen. Während wir migrieren, wächst eine übergeordnete Spezifikation des neuen Systems mit, dazu eine dokumentierte Historie aller Changes. Bei alten Systemen fehlt typischerweise genau diese Gesamtsicht.
Diese vier Schritte erlauben es uns, Anwendungscode mittels AI zu generieren, der gegen eine klare Spezifikation gebaut wurde, durch Golden Master Tests abgesichert ist, und von einem Regelwerk-Sicherheitslayer geschützt wird. Das Risikoprofil sieht damit fundamental anders aus, als wenn man die ursprüngliche Applikation ohne diese Leitplanken durch AI migrieren lässt.
Je näher am Fundament, desto genauer hinschauen
In unserem Vorgehen steckt ein Muster. Nicht jede Schicht braucht dasselbe Mass an Kontrolle.
Tests, Datenbank-Schema und Security-Konfiguration reviewen wir streng manuell. Das sind die tragenden Wände. Bei Anwendungscode, Tooling und Migrationsskripten geben wir der AI mehr Spielraum. Die Leitplanken stehen ja bereits: Tests fangen Fehler ab, Regelwerk schützt die Daten.
Und auch dort wandert kein Code ungesehen in den Hauptzweig. Jeder Pull Request wird von einer Person reviewt, egal ob ein Mensch oder ein Agent ihn geschrieben hat. Das ist der Human-in-the-loop, der den ganzen Prozess trägt.
Das ist für uns die Grenze zwischen Vibe Coding und professionellem Einsatz von AI. Nicht ob man AI nutzt, sondern wo man ihr wie viel Verantwortung gibt.
Kein Mammutprojekt, sondern ein klarer Prozess
Legacy-Ablösung muss kein Projekt sein, das man jahrelang vor sich herschiebt. Entscheidend ist der Prozess: zuerst das Verhalten absichern, dann die Sicherheit aufsetzen, dann Schicht für Schicht migrieren. Mit AI an den richtigen Stellen lässt sich auch ein über Jahre gewachsenes System in überschaubarer Zeit ablösen. Wer ein ähnliches Vorhaben plant, dem erzählen wir gerne, wie das bei uns aussieht.
