Der Product Manager ist tot. Es lebe der Product Developer.
Die Person, die mit Figma-Entwürfen ins Meeting kommt und sagt 'baut das', hat keine Zukunft mehr. KI hat den Abstand...
10 Min. Lesezeit
07.03.2026, Von Stephan Schwab
Wenn Ihr Unternehmen auf einer zehn Jahre alten Anwendung mit VBA-Anpassungen läuft, die niemand mehr vollständig versteht, ist Modernisierung keine Option — sie ist Überleben. Der Erfolg erfordert den Einsatz von KI zur Wissensextraktion aus Legacy-VBA, den Aufbau von Java-Testsuiten zur Validierung und die Anwendung des Schweizer-Käse-Modells, um sicherzustellen, dass Ihre neue Implementierung exakt die gleichen Ergebnisse liefert. Denn fast richtig bedeutet geschäftliches Scheitern.
Irgendwo in Ihrem Unternehmen gibt es eine Geschäftsanwendung. Sie existiert seit fünfzehn Jahren. Es begann als Standardsoftware, aber der Hersteller stellte VBA für Anpassungen bereit, und Ihre Organisation nutzte das. Was als einfache Automatisierung begann, wuchs zu geschäftskritischer Logik und steuert heute Preisentscheidungen im Wert von Millionen. Die Person, die diese Anpassungen schrieb, ging 2019 in den Ruhestand. Die Dokumentation ist der Code selbst — wenn man das Dokumentation nennen kann.
Dies ist kein hypothetisches Szenario. Ich sehe ähnliche Situationen regelmäßig. Die VBA-Anpassungen, die Versicherungsprämien in einem Bestandsführungssystem berechnen. Die Buchhaltungssoftware mit VBA-Skripten, die internationale Zahlungen abgleichen. Die CRM-Plattform, in der VBA komplexes Lead-Scoring automatisiert. Alles geschäftskritisch. Alles unersetzlich. Alles beängstigend.
Wenn Organisationen sich endlich entscheiden, diese Systeme zu modernisieren, stehen sie vor einem grundlegenden Problem: Niemand weiß genau, was das System tut. Sie wissen, was es tun soll. Sie wissen, welche Knöpfe zu drücken sind. Aber die eigentliche Logik — die Randfälle, die Sonderbehandlungen, die Eigenheiten, die sich über Jahre von Patches angesammelt haben — existiert nur im Code.
Die meisten Legacy-Modernisierungsprojekte scheitern aus einem einfachen Grund: Das neue System liefert nicht die gleichen Ergebnisse wie das alte.
Das klingt offensichtlich. Natürlich sollte das neue System dem alten entsprechen. Aber Übereinstimmung ist schwieriger, als es scheint. Eine Preisberechnung, die um 0,3% abweicht, mag akzeptabel erscheinen, bis man realisiert, dass 0,3% bei zehntausend Transaktionen pro Tag zu einer signifikanten Umsatzabweichung führen. Die Finanzabteilung bemerkt es. Wirtschaftsprüfer stellen Fragen. Vertrauen verfliegt.
Das Problem ist nicht die technische Fähigkeit. Moderne Entwickler können elegante Systeme bauen. Das Problem ist die Wissensextraktion. Wie erfassen Sie, was das Legacy-System tatsächlich tut, einschließlich aller undokumentierten Verhaltensweisen, die zu Geschäftsanforderungen geworden sind, einfach weil sie seit Jahren so geschehen?
Hier wird KI wirklich nützlich — nicht als Ersatz für Entwickler, sondern als archäologischer Assistent, der sich nie langweilt, schrecklichen Code zu lesen.
VBA, das 2008 von einem Finanzexperten geschrieben wurde, der Programmieren durch Versuch und Irrtum lernte, hat einen besonderen Charakter. Variablen namens temp2, finalFinal und dasHierGeht. Funktionen, die 400 Zeilen umfassen. Zusammenkopierte Blöcke mit subtilen Variationen. Kommentare, die sagen “nicht anfassen”, ohne zu erklären warum.
Ein KI-Assistent kann diesen Code lesen und Bedeutung extrahieren, für die ein menschlicher Entwickler Tage brauchen würde, um sie zusammenzusetzen. Füttern Sie ihn mit einem 2000-Zeilen-VBA-Modul und fragen Sie: “Welche Geschäftsregeln sind in dieser Funktion kodiert?” Die KI identifiziert die Berechnungsschritte, notiert die bedingten Verzweigungen und beschreibt die Logik in klarer Sprache.
Dieser Arbeitsablauf ist besonders effektiv in IDEs wie VS Code, wo Sie einen laufenden Dialog mit der KI führen können. Sie können sie bitten, bestimmte Codeabschnitte zu analysieren und ihre Ergebnisse in einer separaten Markdown-Datei zu dokumentieren — was ein strukturiertes Untersuchungsprotokoll erstellt. Diese Datei wird im Wesentlichen zu Ihrer Navigationskarte, die zweideutige Logik, hartkodierte Konstanten oder seltsame Abhängigkeiten hervorhebt, die weitere Untersuchung erfordern.
Aber hier ist der kritische Punkt: Die Interpretation der KI ist eine Hypothese, kein verifizierter Fakt. Die KI könnte obskure VBA-Syntax missverstehen. Sie könnte Kontext übersehen, der nur Sinn ergibt, wenn man die Geschäftsdomäne kennt. Sie könnte selbstbewusst Logik erklären, die der ursprüngliche Autor falsch gemacht hat, und diese Falschheit ist zum erwarteten Verhalten geworden.
Sie können der Ausgabe der KI nicht direkt vertrauen. Sie benötigen Validierung.
Die Lösung ist der Aufbau einer umfassenden Testsuite, bevor eine einzige Zeile Ersatzcode geschrieben wird. Nicht Tests, die Ihr Verständnis davon verifizieren, was das System tun sollte — Tests, die erfassen, was das System tatsächlich tut.
Dies erfordert, das Legacy-System mit bekannten Eingaben auszuführen und die Ausgaben aufzuzeichnen. Jedes Szenario. Jeder Randfall, den Sie identifizieren können. Jede Kombination von Parametern, die das Geschäft in der Praxis nutzt.
@ParameterizedTest
@MethodSource("legacyCalculationTestCases")
void newCalculation_MatchesLegacyOutput(
CalculationInput input,
LegacyOutput expectedOutput) {
var result = newCalculationEngine.calculate(input);
assertEquals(expectedOutput.getPremium(), result.getPremium(), 0.0001);
assertEquals(expectedOutput.getTax(), result.getTax(), 0.0001);
assertEquals(expectedOutput.getFees(), result.getFees(), 0.0001);
}
KI-Werkzeuge beschleunigen den Aufbau dieses Gerüsts. Anstatt manuell zu bestimmen, welche Eingaben alle Codepfade abdecken, füttern Sie die VBA-Logik an einen KI-Assistenten. Bitten Sie ihn, Grenzwerte und Bedingungsauslöser zu identifizieren. Er wird erkennen, dass Zeile 403 auf Transaktionen über 10.000 € prüft und einen Testfall für 10.001 € vorschlagen. Er kann auch die Java-Datenstrukturen (DTOs) direkt aus den VBA-Typdefinitionen generieren und die mühsame Syntaxübersetzung sofort erledigen.
Wir können noch weiter gehen. Unter menschlicher Aufsicht in einem ständigen Dialog kann sie die Tests in TDD-Manier aufbauen. Anstatt zu versuchen, das gesamte System auf einmal zu verstehen, nutzen Sie die KI, um Regeln inkrementell zu entdecken und mit Tests festzuschreiben. Dieser interaktive Prozess behält den Menschen in Kontrolle — die Logik verifizierend —, während die KI die Schwerarbeit von Syntax und Struktur übernimmt.
Manchmal ist das Ausführen des Legacy-VBA aufgrund von Umweltabhängigkeiten schwierig. In diesen Situationen kann die KI die Logikstruktur analysieren, um sinnvolle synthetische Testdaten zu generieren. Sie identifiziert die notwendigen Eingabekombinationen, um spezifische Pfade auszulösen, was Ihnen ermöglicht, umfassende Testszenarien aufzubauen, selbst wenn die ursprüngliche Laufzeitumgebung fragil ist.
Die Testfälle kommen aus dem Legacy-System. Führen Sie das VBA mit diesen Eingaben aus, erfassen Sie diese Ausgaben, speichern Sie sie als Ihre Validierungsbasis (Golden Master). Jetzt haben Sie ein Orakel — eine Quelle der Wahrheit, die korrektes Verhalten nicht durch Spezifikation, sondern durch Beobachtung definiert.
Im Wesentlichen bauen wir zu diesem Zeitpunkt ein Modell des alten Systems. Wir entwerfen noch nicht die neue Architektur; wir erstellen eine hochgenaue Verhaltenskarte der Legacy-Anwendung. Dieses ausführbare Modell wird zur Anforderungsspezifikation, die kein schriftliches Dokument je erreichen könnte.
Dieser Ansatz hat einen Namen in Testkreisen: Charakterisierungstests, oder manchmal Golden-Master-Tests. Sie charakterisieren bestehendes Verhalten, spezifizieren kein neues Verhalten. Das Legacy-System ist die Spezifikation.
Hier wird das Schweizer-Käse-Modell essentiell. James Reason entwickelte dieses Modell, um zu erklären, wie Unfälle in komplexen Systemen geschehen. Die Idee ist einfach: Jede Verteidigungsschicht hat Löcher, wie Scheiben von Schweizer Käse. Ein Unfall passiert, wenn die Löcher sich ausrichten und eine Gefahr durch alle Schichten passieren lassen.
Dies erfordert einen psychologischen Wandel. Menschen im Allgemeinen sind darauf trainiert, Perfektion zu suchen — die richtige Antwort, die fehlerfreie Funktion, die vollständige Spezifikation. Komplexität und Mehrdeutigkeit fühlen sich wie Versagen an. Aber in der Legacy-Modernisierung ist die Suche nach einer einzigen “perfekten” Validierungsmethode eine Falle. Sie führt zu Analyse-Paralyse.
Wir müssen akzeptieren, dass jedes Werkzeug und jede Schicht fehlerbehaftet sein wird. Die KI wird manche Logik missinterpretieren. Die Testdaten werden ein Szenario verpassen. Der Schattenbetrieb wird einen saisonalen Randfall nicht erfassen. Diese Unvollkommenheit zu akzeptieren ist kein Defätismus; es ist die statistische Realität komplexer Systeme. Indem wir anerkennen, dass keine einzelne Schicht vertrauenswürdig ist, sind wir gezwungen, Resilienz durch Redundanz aufzubauen.
Bei der Legacy-Modernisierung ist die Gefahr fehlerhaftes Verhalten, das in die Produktion rutscht. Jede Validierungsschicht fängt einige Probleme, verpasst aber andere. Die Lösung ist nicht, die perfekte Schicht zu finden — sie ist, mehrere unperfekte Schichten zu stapeln, damit ihre Löcher sich nicht ausrichten.
Schicht 1: KI-unterstützte Code-Analyse. Lassen Sie die KI erklären, was jede VBA-Funktion tut. Überprüfen Sie ihre Interpretation. Stellen Sie Folgefragen. Bauen Sie ein mentales Modell des Systems.
Schicht 2: Input/Output-Erfassung. Extrahieren Sie reale Berechnungsbeispiele aus dem Legacy-System. Keine synthetischen Testfälle — tatsächliche historische Eingaben und ihre entsprechenden Ausgaben.
Schicht 3: Charakterisierungstests. Bauen Sie die Java-Testsuite, die Ihre neue Implementierung gegen die erfassten Baselines (Golden Master) laufen lässt. Jeder fehlschlagende Test offenbart einen Verhaltensunterschied.
Schicht 4: Schattenbetrieb (Shadow Running). Liefern Sie das neue System neben dem alten aus. Führen Sie reale Transaktionen durch beide aus. Vergleichen Sie Ausgaben kontinuierlich. Alarmieren Sie bei jeder Abweichung.
Schicht 5: Gestaffelter Rollout mit Rollback. Verarbeiten Sie eine Teilmenge von Live-Transaktionen mit dem neuen System. Überwachen Sie auf Abweichungen. Erhöhen Sie das Volumen nur, wenn das Vertrauen hoch ist.
Schicht 6: Fachliche Validierung. Lassen Sie fachliche Experten Stichproben prüfen. Ergeben die Zahlen Sinn? Verhalten sich Randfälle korrekt? Vertrauen Sie ihrer Intuition — sie nutzen dieses System seit Jahren.
Keine einzelne Schicht ist ausreichend. KI-Interpretation könnte Feinheiten übersehen. Charakterisierungstests könnten seltene Randfälle nicht abdecken. Schattenbetrieb könnte nicht jeden Codepfad ausführen. Aber stapeln Sie alle sechs Schichten, und die Wahrscheinlichkeit, dass ein signifikanter Defekt die Produktion erreicht, sinkt dramatisch.
Es gibt einen sekundären Nutzen dieses Ansatzes, der sich oft als wertvoller erweist als die Modernisierung selbst: explizites Wissen.
Das Legacy-VBA kodierte Geschäftsregeln implizit. Niemand konnte diese Regeln artikulieren, ohne den Code zu lesen. Jetzt haben Sie eine Testsuite mit Hunderten von dokumentierten Beispielen. Die KI-generierten Erklärungen, überprüft und korrigiert, werden zur Prosa-Dokumentation. Die Charakterisierungstests werden zu ausführbaren Spezifikationen.
Wenn der nächste Entwickler zum Team stößt, muss er kein VBA-Modul zurückentwickeln. Er kann die Tests lesen. Er kann genau sehen, welche Eingaben welche Ausgaben produzieren. Er kann die Geschäftsregeln durch Beispiele verstehen, statt durch archäologische Ausgrabung.
Wenn Sie vor einem Legacy-VBA-Modernisierungsprojekt stehen, fangen Sie hier an:
Bestandsaufnahme und Bewertung. Listen Sie jedes VBA-Modul, jedes Formular und jedes Makro auf. Notieren Sie, welche geschäftskritisch sind und welche Komfort-Hilfsmittel sind. Identifizieren Sie die Komponenten mit dem höchsten Risiko — diejenigen, die Geld, Compliance oder Kundendaten verarbeiten.
Wissen mit KI extrahieren. Füttern Sie den kritischen VBA-Code an einen KI-Assistenten. Bitten Sie ihn, die Geschäftslogik zu erklären. Nutzen Sie den Dialog in Ihrer IDE, um Erkenntnisse in einer Datei zu dokumentieren, die die weitere Untersuchung leitet. Markieren Sie Bereiche der Unsicherheit.
Das Orakel erfassen. Führen Sie das Legacy-System mit repräsentativen Eingaben aus. Zeichnen Sie jede Ausgabe auf. Bauen Sie Ihren Golden-Master-Datensatz.
Den Testgerüst bauen. Erstellen Sie die Java-Testsuite. Verifizieren Sie, dass das Ausführen der erfassten Eingaben durch das Legacy-System die erfassten Ausgaben produziert. Das klingt zirkulär, validiert aber Ihren Erfassungsprozess.
Inkrementeller Ersatz. Schreiben Sie eine Funktion nach der anderen neu. Führen Sie die Charakterisierungstests nach jeder Änderung aus. Abweichungen sind Defekte, bis das Gegenteil bewiesen ist.
Der Schlüssel ist Geduld. Diesen Prozess zu überstürzen, lädt genau die Fehler ein, die Legacy-Modernisierung berüchtigt machen. Jede Validierungsschicht braucht Zeit zur Implementierung. Diese Zeit ist eine Investition in Vertrauen.
Organisationen verzögern Legacy-Modernisierung oft, weil sich das Risiko hoch anfühlt. Was, wenn das neue System etwas kaputt macht? Was, wenn wir Funktionalität verlieren? Was, wenn Kunden Probleme bemerken?
Diese Bedenken sind valide. Aber sie müssen gegen das Risiko des Nichtstuns abgewogen werden. Der VBA-Entwickler, der das System wartet, geht in Rente. Die Plattform des Herstellers nähert sich dem Support-Ende. Die Audit-Anforderungen werden strenger. Das Geschäft wächst schneller, als die Legacy-Anpassungen bewältigen können.
Das Risiko der Modernisierung ist sichtbar und handhabbar. Das Risiko fortgesetzter Stagnation ist lautlos, bis es katastrophal wird — der Tag, an dem die Anwendung korrumpiert, der Tag, an dem die einzige Person, die sie versteht, geht, der Tag, an dem ein Prüfer nach Dokumentation fragt, die nicht existiert.
Legacy-VBA zu modernisieren ist kein Technologieproblem. Es ist ein Problem der Wissensextraktion mit einer Validierungsanforderung, die Tiefenverteidigung (Defense in Depth) verlangt.
KI beschleunigt die Extraktionsphase. Java-Tests bieten den Validierungsrahmen. Das Schweizer-Käse-Modell stellt sicher, dass kein einzelner Fehlermodus das Ergebnis kompromittieren kann.
Die Alternative — neu schreiben basierend auf Annahmen darüber, was das System tun sollte — ist, wie Modernisierungsprojekte scheitern. Gleiche Ergebnisse ist der einzige akzeptable Standard, wenn Geschäftskontinuität vom Ergebnis abhängt.
Die Anwendung, die Ihr Geschäft betreibt, verdient mehr als Hoffnung. Sie verdient Validierungsschichten, die so robust sind, dass Vertrauen die Angst ersetzt. Fangen Sie heute an, diese Schichten zu bauen.
Sprechen wir über Ihre reale Situation. Möchten Sie Auslieferung beschleunigen, technische Blockaden beseitigen oder prüfen, ob eine Idee mehr Investition verdient? Ich höre Ihren Kontext und gebe 1-2 praktische Empfehlungen. Ohne Pitch, ohne Verpflichtung. Vertraulich und direkt.
Zusammenarbeit beginnen