Modernisierung

Warum "einfach Claude Code darauf ansetzen" kein Rettungsplan ist

Eine verbreitete Vorstellung in der Modernisierung von Altsystemen ist, dass man ein KI-Coding-Tool einfach auf ein altes System ansetzt und dann eine saubere Ersatzlösung erhält. Für Führungsteams klingt das effizient, risikoarm und schnell. In der Praxis ist es meist ein Missverständnis darüber, wo der eigentliche Wert und die eigentliche Schwierigkeit liegen.

Die schwierige Arbeit besteht selten darin, eine Programmiersprache in eine andere zu übertragen. Die schwierige Arbeit besteht darin, Geschäftslogik, Sonderfälle, Bedienerabkürzungen, Freigaben, Datenannahmen und versteckte Abhängigkeiten zu finden, die sich über Jahre realer Nutzung im alten System angesammelt haben.

Warum die Idee plausibel klingt

Wenn ein Legacy-System Code in einer erkennbaren Sprache wie VBA oder klassischem Visual Basic enthält, liegt der Gedanke nahe, moderne Werkzeuge könnten diesen Code in etwas Neueres übersetzen. Auf einem engen technischen Ausschnitt stimmt das auch. Eine Prozedur kann umgeschrieben werden. Eine Berichtsanfrage kann neu formuliert werden. Ein Event-Handler eines Bildschirms kann in eine andere Sprache übertragen werden.

Das ist der Teil, den man sehen kann. Es ist nicht der Teil, an dem solche Projekte typischerweise scheitern.

Wobei das Werkzeug helfen kann

Werkzeuge wie Claude Code können beim Lesen von Code, beim Erklären von Routinen, beim Erkennen von Wiederholungen, beim Entwerfen von Migrationen, beim Vergleichen von Mustern und beim Beschleunigen von Dokumentation sehr nützlich sein. Sie können ein Team schneller machen, sobald das System gut genug verstanden ist.

Das ist etwas anderes, als zu behaupten, das Werkzeug verstehe das Geschäft gut genug, um das System sicher zu ersetzen.

Warum reine Übersetzung nicht ausreicht

Ein Legacy-System ist meist nicht nur Code. Es ist ein funktionierendes Zusammenspiel aus Software, Menschen, Daten, Zeitpunkten und Prozessen. Selbst dort, wo Code existiert, ist er nur eine Ausdrucksform der Geschäftsregeln.

Der Code kann als Spezifikation unvollständig sein: Das tatsächliche Verhalten kann von Formularen, Berichten, gespeicherten Abfragen, Konfiguration, Benutzerrechten oder der Reihenfolge abhängen, in der Mitarbeitende Schritte ausführen.
Das System kann auf versteckten Annahmen beruhen: Dateiablagen, alte Treiber, Tabellenformate, Drucklayouts, gemeinsam genutzte Ordner oder manuelle Prüfungen erfahrener Mitarbeitender.
Die wichtigsten Regeln sind oft nicht klar benannt: Entwickler und Nutzer haben Sonderfälle häufig im Laufe der Zeit ergänzt, ohne sie sauber zu dokumentieren.
Die Sprache kann übersetzt werden, während das Verhalten verloren geht: Eine technisch korrekte Neufassung kann das Geschäft dennoch beschädigen, wenn Timing, Reihenfolge, Validierung oder Ausnahmebehandlung fehlen.

Beispiel: VBA

VBA ist ein gutes Beispiel, weil es eine echte Programmiersprache ist und sich oft lesen und übersetzen lässt. Eine VBA-lastige Lösung hängt aber meist von mehr ab als nur von den Code-Modulen. Das tatsächliche Verhalten steckt oft auch in der Struktur von Arbeitsmappen, Formularelementen, versteckten Tabellenblättern, benannten Bereichen, Access-Formularen, Berichtslayouts, Ereignisbindungen und der Art, wie Benutzer Eingaben vorbereiten und prüfen.

Wer nur die VBA-Prozeduren übersetzt, kann die Syntax retten und trotzdem das Betriebsmodell verlieren.

Beispiel: Visual Basic

Klassische Visual-Basic-Anwendungen wirken ebenfalls oft täuschend überschaubar. Es gibt Quellcode, Formulare und Event-Handler. Dadurch sieht das Umschreiben wie eine reine Sprachkonvertierung aus.

In der Praxis hängt das Geschäftsverhalten jedoch häufig vom Zusammenspiel aus Formularen, gemeinsamen Modulen, Datenbankabfragen, Berichtskomponenten, Konfigurationsdateien und lokalen Konventionen ab, die niemand dokumentiert hat, weil das System längst "einfach so funktioniert". Die Übersetzung des Codes rekonstruiert diese Konventionen nicht automatisch.

Wovon die Unternehmensleitung stattdessen ausgehen sollte

Die sicherere Annahme lautet: KI kann Teile von Rescue und Modernisierung beschleunigen, beseitigt aber nicht die Notwendigkeit von Discovery, Validierung und Extraktion der Geschäftsregeln. Legacy Rescue braucht weiterhin Menschen, die klären, was das System tatsächlich tut, was erhalten bleiben muss, was stillgelegt werden kann und wo das eigentliche Risiko liegt.

Diese Arbeit ist besonders wichtig in Unternehmen, in denen die ursprünglichen Erbauer nicht mehr da sind, die IT-Kapazität begrenzt ist oder die Software Ausnahmen abbildet, die von den Hauptsystemen nie sauber unterstützt wurden.

Wie ein ernsthafter Rescue-Ansatz aussieht

Artefakte inventarisieren: Code, Formulare, Berichte, Abfragen, Tabellen, Makros, Jobs, Exporte und Integrationen.
Geschäftskritische Abläufe identifizieren: also das, was sich die Organisation nicht leisten kann, falsch zu machen.
Ausnahmen und Bedienwissen erfassen: genau die Fälle, an die sich niemand erinnert, bis sie ausfallen.
KI als Beschleuniger nutzen, nicht als Quelle der Wahrheit: hilfreich für Analyse und Entwürfe, aber kein Ersatz für echtes Verständnis.
Gegen reale Betriebsabläufe validieren: die Ersatzlösung muss Ergebnisse erhalten, nicht nur dem alten Code ähnlich sehen.

Die praktische Schlussfolgerung

Die Frage ist nicht, ob Claude Code oder ähnliche Werkzeuge nützlich sind. Das sind sie. Die Frage ist, ob sie die Notwendigkeit beseitigen, die im alten System eingebettete Geschäftslogik zu verstehen. Das tun sie nicht.

Wenn eine Organisation ein Legacy-Rewrite als reine Übersetzungsaufgabe behandelt, riskiert sie, die sichtbare Software zu bewahren und zugleich das Arbeitswissen zu verlieren, das das Geschäft funktionsfähig gemacht hat. Deshalb beginnt Legacy Rescue mit Extraktion und Verständnis, nicht mit blinder Konvertierung.

Weiterführend von Caimito Agile Life

Diese Artikel vertiefen dasselbe Problem aus den Blickwinkeln Discovery, Governance und Validierung.