Eine geschäftskritische Pflegesoftware, gewachsen auf Oracle und PL/SQL, soll auf Azure, .NET und React – ohne dass sich eine einzige fachliche Funktion ändert. In einer Workshop-Woche haben wir dafür eine Methodik entwickelt und dreimal am echten System getestet. Das Ergebnis ist ein Blueprint, der zeigt, wo KI bei der Modernisierung wirklich Zeit spart – und wo sie ohne menschliche Führung Schaden anrichtet.

vom Legacy-Code
zum belastbaren Blueprint

jede Iteration besser
als die vorherige

gefunden, bevor die
erste Zeile Code entstand

im dritten Durchlauf und
damit direkt weiterentwickelbar
Ein führendes Hygiene- und Gesundheitsunternehmen betreibt eine Pflegemanagement-Software, mit der Altenpflegeeinrichtungen in fünf Ländern Bewohnerdaten verwalten, Versorgungspläne erstellen und Bestellungen auslösen. Fachlich ist die Anwendung über Jahre gereift. Technisch steht sie am Ende ihres Lebenszyklus: Oracle-Datenbank, Geschäftslogik in PL/SQL, kaum noch Entwickler, die beides beherrschen.
Das Ziel: eine Cloud-Architektur auf Microsoft Azure mit .NET und React – bei identischem Funktionsumfang. Die eigentliche Frage war nicht, ob KI dabei hilft. Sondern wo genau, unter wessen Kontrolle, und woran man merkt, dass es funktioniert.
Am Anfang steht kein Prompt, sondern Inventur: Quellcode, Datenmodell, Schnittstellen, Dokumentation und das Wissen der Menschen, die das System seit Jahren betreiben. Eine Erfahrung aus dem Workshop, die man selten liest: Für den Ersteindruck und die grundlegenden Architekturentscheidungen braucht es erfahrene Entwickler, nicht KI. Danach spielt die KI ihre Stärke aus – sie erklärt Legacy-Code, kartiert Abhängigkeiten und markiert Risiken schneller, als ein Mensch die Dateien öffnen kann.
Eine KI kann fehlende Informationen nicht ersetzen, aber sie findet sie zuverlässig. In dieser Phase prüft sie Anforderungen auf Vollständigkeit und Widersprüche und stellt die Fragen, die sonst erst mitten im Sprint auffallen. Im Workshop deckte eine mehrstufige Konsistenzprüfung 19 Widersprüche zwischen Datenbankschema, Architekturdokumenten und Anforderungen auf – vor der ersten Zeile Code. Die Alternative wären 19 einzelne Abstimmungsrunden gewesen, verteilt über Monate.
Bevor produktiver Code entsteht, schreibt die KI einen Plan: Reihenfolge, Schnittstellen, Technologieversionen, Quality Gates – und explizit auch, welche Ressourcen sie nicht verwenden darf. Dann folgt der Dry Run: Die KI prüft ihren eigenen Plan auf Widersprüche, ohne das System anzufassen. Fehlannahmen kosten hier eine Korrekturschleife statt eines Refactorings.
Erst jetzt wird Code generiert → in einem von drei Modi, je nachdem, wie kritisch der Baustein ist. Das Team prüft, korrigiert und entscheidet – über Architektur, Sicherheit und fachliche Korrektheit. Human-in-the-Loop ist hier kein Feigenblatt, sondern ein eingeplanter Checkpoint nach jeder Phase.
Wie viel Autonomie verträgt KI-gestützte Codegenerierung? Die ehrliche Antwort: Es kommt darauf an, was auf dem Spiel steht. Deshalb arbeitet unsere Methodik nicht mit einer festen Einstellung, sondern mit drei bewusst wählbaren Ausführungsmodi.
Im Exploration-Modus läuft die KI ohne Checkpoints durch. Das ist der schnellste Weg zu einem Ergebnis – und genau richtig, wenn das Ergebnis eine Erkenntnis sein soll, kein Produkt: Machbarkeitsstudien, Prototypen, technische Experimente. Unsere drei Prototyp-Iterationen im Workshop sind so entstanden.
Der Controlled-Modus ist der Standard für produktionsnahe Portierung. Die KI arbeitet eine Phase eigenständig ab, dann prüft das Team: Stimmt die Architektur? Hält sich die Umsetzung an den Plan? Erst nach der Freigabe geht es weiter. So bleibt das Tempo hoch, ohne dass Fehlentwicklungen unbemerkt wachsen.
Im Guided-Modus steht nach jedem einzelnen Task ein Checkpoint. Das kostet Geschwindigkeit – und ist sie wert, wenn kritische Geschäftslogik übertragen wird, bei der ein stiller Fehler teurer ist als jede Verzögerung.
Welcher Modus der richtige ist, entscheidet nicht die KI, sondern das Team – pro Baustein, nicht pro Projekt.
Drei vollständige Iterationen zeigten eine klare Lernkurve. Der erste Durchlauf lief ohne Spezifikation: funktionierender, aber ungeordneter Code. Der zweite, mit Grundspezifikation, wurde besser – die KI füllte Lücken mit eigenen Annahmen. Der dritte Lauf bekam vollständige Architektur, Implementierungsplan und nicht-funktionale Anforderungen. Ergebnis: aktuelle Packages, saubere Struktur, keine kritischen technischen Schulden. Das Entwicklungsteam bewertete den Stand als direkt weiterentwickelbar.
- Tech Lead des Kunden – sein Feedback nach der Anforderungsphase: „Ergebnisse von Claude sind sehr gut.“

KI ignoriert gelegentlich explizite Vorgaben. Im Workshop wählte sie trotz klarer Anweisung eine andere Framework-Version und CSS statt SCSS. Kritische Vorgaben gehören deshalb mehrfach in den Plan – direkt in die betroffenen Arbeitsschritte, nicht nur in die Präambel.

KI erweitert ihren Auftrag, wenn niemand den Rahmen setzt. Sie nutzt alles, was sie findet – auch Artefakte, die das Team längst verworfen hat. Verbotenes muss schriftlich verboten werden.

KI sagt nie „passt, ist fertig“. Sie findet immer noch etwas zu verbessern. Wann eine Iteration gut genug ist, bleibt eine menschliche Entscheidung – sonst verfeinert man endlos ohne Mehrwert.
Wir bringen erfahrene Entwickler und die erprobte Methodik mit, Sie Ihr System und Ihr Fachwissen. Gemeinsam analysieren wir Ihre Anwendung, bauen eine geprüfte Spezifikation und testen die Portierung an einem echten Ausschnitt Ihres Systems.
Nach fünf Tagen haben Sie: einen belastbaren Blueprint für die Modernisierung, einen lauffähigen Prototyp und eine ehrliche Antwort darauf, wo KI Ihrem Team Zeit spart – und wo nicht. Die Methodik ist werkzeugagnostisch: Sie funktioniert mit Claude, GitHub Copilot oder Ihrem internen Sprachmodell.
KI beschleunigt Analyse, Spezifikation und Implementierung erheblich, aber Architekturentscheidungen, fachliche Bewertung und Qualitätskontrolle brauchen erfahrene Entwickler.
Vollautonome Modernisierung geschäftskritischer Software erzeugt Code, der funktioniert, aber schwer wartbar ist – das hat sich im Projekt konkret gezeigt.
Vor dem Code: beim Verstehen des Legacy-Systems, beim Vervollständigen der Anforderungen und beim Aufdecken von Widersprüchen. In unserem Workshop fand die KI 19 Inkonsistenzen zwischen Datenbankschema, Architektur und Anforderungen, bevor die Implementierung begann.
Ein Dry Run ist die Prüfung des Implementierungsplans vor der Umsetzung: Die KI kontrolliert ihren eigenen Plan auf Widersprüche, fehlende Informationen und Risiken, ohne Code zu schreiben oder das System zu verändern. Fehler werden so korrigiert, bevor sie Folgekosten verursachen.
Nein. Der Blueprint ist werkzeugagnostisch und funktioniert mit Claude, GitHub Copilot, IDE-integrierten KI-Funktionen oder unternehmensinternen Sprachmodellen. Entscheidend sind die Prozessschritte und Kontrollmechanismen, nicht das Modell.
Für gewachsene Datenbankanwendungen (etwa Oracle/PL-SQL), monolithische Systeme, veraltete Frontends und On-Premises-Software, die in die Cloud soll. Voraussetzung ist Zugriff auf Quellcode oder zumindest belastbare Dokumentation des Bestandssystems.
Durch vollständige Spezifikation vor der Generierung, kleine Umsetzungsschritte mit Quality Gates, automatisierte Tests und Reviews nach jeder Phase. Im dritten Prototyp-Durchlauf – mit vollständiger Architektur und Implementierungsplan – entstand Code ohne kritische technische Schulden.