Warum Legacy-Software so lange im Einsatz bleibt
Eine Anwendung kann fünfzehn Jahre alt und dennoch unverzichtbar für das Unternehmen sein. Sie verarbeitet Bestellungen, verwaltet Kundenkonten oder verbindet Systeme, die im Laufe der Jahre um sie herum entstanden sind. Alle wünschen sich, dass sie leichter zu warten wäre. Niemand möchte jedoch erst beim Austausch herausfinden, was anschließend nicht mehr funktioniert.
Deshalb bleibt ältere Software oft lange im Einsatz, obwohl das Unternehmen sie lieber modernisieren würde. Die Investition in eine Nachfolgelösung muss sich rechnen – und der Geschäftsbetrieb muss während der Arbeiten weiterlaufen.
KI gibt Unternehmen einen guten Anlass, solche Entscheidungen neu zu bewerten. Sie kann Entwicklerinnen und Entwickler dabei unterstützen, unbekannten Code zu verstehen, Komponenten zu aktualisieren und Tests vorzubereiten. Manche Projekte, die bislang zu teuer erschienen, könnten sich dadurch wieder lohnen. Um das realistisch beurteilen zu können, müssen wir jedoch den gesamten Weg von der bestehenden Anwendung bis zu einer zuverlässigen Nachfolgelösung betrachten.
Was die bisherigen Ergebnisse zeigen – und was nicht
Für die Aufbruchsstimmung gibt es durchaus Belege. Drei randomisierte Feldexperimente mit insgesamt 4.867 Entwicklerinnen und Entwicklern ergaben, dass der Zugang zu einem KI-Programmierassistenten die Zahl der erledigten Aufgaben um rund 26 % erhöhte. Das ist eine relevante Verbesserung. Daraus folgt allerdings nicht, dass ein vollständiges Modernisierungsprojekt automatisch 26 % weniger kostet.
Es gibt auch Beispiele, die näher an der eigentlichen Modernisierungsarbeit liegen. Laut einer Fallstudie von Anthropic schloss LG CNS eine unternehmensweite Migration in sieben Monaten ab – zu ungefähr der Hälfte der für einen konventionellen Neubau geschätzten Kosten. Das ist ein vielversprechendes, vom Anbieter veröffentlichtes Ergebnis. Der Vergleich basiert allerdings auf den erwarteten Kosten der Alternative.
Solche Ergebnisse sprechen dafür, die Werkzeuge in einem realen Projekt zu erproben. Für die eigene Anwendung bleibt dennoch zu klären, wie viel Aufwand in Integration, Datenmigration und den Nachweis fließt, dass sich das System weiterhin korrekt verhält.
Vor einem Rewrite zuerst die eigentliche Hürde bestimmen
Bevor Sie sich für die Neuentwicklung einer Anwendung entscheiden, sollten Sie feststellen, was den Betrieb und die Weiterentwicklung tatsächlich erschwert. Vielleicht wird ein Framework nicht mehr unterstützt. Vielleicht erfordert jede neue Funktion Änderungen in mehreren Systemen. Oder eine einzige problematische Komponente verursacht den größten Teil des Wartungsaufwands.
Jede dieser Situationen verlangt nach einer anderen Lösung. Ein Update der Laufzeitumgebung oder der Austausch einer einzelnen Komponente kann bereits den benötigten geschäftlichen Nutzen liefern. Eine vollständige Neuentwicklung ist dann sinnvoll, wenn ihr Wert den Aufwand rechtfertigt, das gesamte System nachzubauen und umfassend zu validieren.
Das Wissen im Altsystem bewahren
Der vorhandene Code kann Wissen enthalten, das über viele Jahre entstanden ist. Eine ungewöhnliche Berechnung existiert vielleicht aufgrund einer besonderen Vertragsregelung. Eine scheinbar überflüssige Prüfung schützt womöglich vor einem Fehler, der nur beim Monatsabschluss auftritt. Solche Details gehen leicht verloren, wenn das Ziel lediglich darin besteht, saubereren Code zu erzeugen.
KI kann Entwicklerinnen und Entwickler dabei unterstützen, diese Details zu untersuchen und die Zusammenhänge innerhalb einer Anwendung zu erklären. Thoughtworks beschreibt den Einsatz von KI zum Verständnis bestehender Systeme als eine wichtige Chance bei der Modernisierung. Die erzeugten Erklärungen müssen dennoch mit dem laufenden System und den Erfahrungen der Menschen abgeglichen werden, die es tatsächlich nutzen.
Nehmen wir eine Abrechnungslogik als Beispiel. Die neue Version kann vollkommen plausibel aussehen und alle Tests bestehen – aber Beträge anders runden als das Altsystem. Dieser Unterschied kann jede einzelne Rechnung betreffen. Bevor die Berechnung ersetzt wird, benötigt das Team abgestimmte Beispiele für die erwarteten Ergebnisse, einschließlich schwieriger Sonderfälle.
KI kann auch beim Erstellen der Tests helfen. Beruhen die Tests jedoch auf derselben falschen Annahme wie der neue Code, werden sie den Fehler nicht erkennen. Historische Beispiele, verlässliche Referenzdaten und eine fachliche Prüfung schaffen eine unabhängige Grundlage für die Validierung.
Mit einem repräsentativen Pilotprojekt den Gesamtaufwand messen
Hier zeigt sich der Wert eines sorgfältig ausgewählten Pilotprojekts. Wählen Sie eine reale Geschäftsfunktion mit einer Integration, eigenen Daten und mindestens einem schwierigen Ausnahmefall. Der Umfang sollte klein genug sein, um das Vorhaben vollständig abzuschließen – und zugleich groß genug, um Erkenntnisse für das Gesamtprojekt zu liefern.
Erfassen Sie den gesamten Aufwand. Die Zeit für die Prüfung von Vorschlägen, die Korrektur von Fehlern und die Untersuchung unerwarteten Verhaltens gehört ebenso in die Rechnung wie die beim Schreiben von Code eingesparte Zeit. Dokumentieren Sie außerdem Fehler und die tatsächliche Durchlaufzeit. Ein schnellerer erster Entwurf ist nur dann wertvoll, wenn das Team daraus effizient ein abgenommenes Ergebnis machen kann.
Stellen Sie den Entwicklerinnen und Entwicklern eine freigegebene Umgebung für die Werkzeuge zur Verfügung, definieren Sie klare Regeln für den Umgang mit Quellcode und Kundendaten und begrenzen Sie die Zugriffsrechte. Eine verantwortliche Person muss weiterhin für die Architektur und die Freigabeentscheidung einstehen.
Eine Fähigkeit nach der anderen ersetzen
Wo immer es sinnvoll ist, sollten Sie die Erkenntnisse aus dem Pilotprojekt nutzen, um einzelne Fähigkeiten des Altsystems schrittweise zu ersetzen. Bei einer solchen Ablösung kann das Unternehmen die Ergebnisse prüfen, während das restliche System weiterarbeitet. Legen Sie fest, wie Daten abgeglichen werden, wie mit Fehlern umzugehen ist und ab welchem Zeitpunkt die alte Komponente endgültig abgeschaltet werden kann.
Mit Bandbreiten planen, nicht mit Versprechen
Für einen ersten Auftrag empfehlen wir, zwei bis vier Wochen für die Analyse der Anwendung und weitere vier bis sechs Wochen für einen repräsentativen Pilotversuch einzuplanen. Danach sollten genügend belastbare Erkenntnisse vorliegen, um fundierter über die nächste Phase, ihr Budget und die zu erwartenden Hindernisse zu entscheiden.
Für das Gesamtprojekt können die folgenden Zeiträume als Ausgangspunkt für die Planung dienen. Es handelt sich um beispielhafte Planungsgrößen, nicht um gemessene Branchendurchschnitte oder verbindliche Lieferzusagen. Die Zeiträume beginnen mit dem Projektstart und schließen – sofern relevant – Analyse und Pilotprojekt ein.
Die ersten beiden Zeiträume setzen ein festes Team von ungefähr vier bis sechs Personen, zugänglichen Quellcode, nutzbare Umgebungen und eine verfügbare fachlich verantwortliche Person voraus. Ein größeres Programm benötigt eine eigene Personalplanung. Unzureichende Datenqualität, externe Lieferanten oder eingeschränkte Release-Zeitfenster können jeden dieser Zeiträume verlängern.
Der Kalender hängt außerdem davon ab, welche Arbeiten durch KI beschleunigt werden. Wird in einem vereinfachten Zwölfmonatsprogramm eine fünfmonatige Entwicklungsphase um 40 % verkürzt, spart das zwei Monate – bevor zusätzlicher Einrichtungs- oder Prüfaufwand berücksichtigt wird. Die übrigen sieben Monate Arbeit müssen weiterhin geleistet werden.
| Projekttyp | Beispielhafter Zeitrahmen |
|---|---|
| Ein klar begrenztes Upgrade oder der Austausch einer Komponente | 2–4 Monate |
| Eine Geschäftsanwendung mit einer überschaubaren Zahl an Integrationen | 4–9 Monate |
| Eine Kernplattform oder ein Portfolio miteinander verbundener Anwendungen | 12–24 Monate oder länger |
Engineering-Beschleunigung in wirtschaftlichen Nutzen übersetzen
Dasselbe Prinzip gilt für die Kosten.
Stellen wir uns ein Modernisierungsprojekt mit einem Budget von 1 Mio. € vor. Davon entfallen 600.000 € auf Arbeiten, die sich mit KI beschleunigen lassen. Reduziert das Team den Aufwand in diesem Bereich bei unveränderten Vergütungssätzen um 40 %, ergibt sich eine Bruttoeinsparung von 240.000 €. Werden weitere 50.000 € für zusätzliche Werkzeuge, Schulungen und Qualitätssicherung eingeplant, beträgt das neue Budget 810.000 €.
Das entspricht einer Nettoeinsparung von 19 %. Es handelt sich um eine beispielhafte Berechnung, nicht um eine Fallstudie von TechHub oder eine Prognose für jedes Projekt. Übliche Tests und Prüfungen sind bereits im Ausgangsbudget enthalten; der zusätzliche Betrag deckt ausschließlich den darüber hinausgehenden Aufwand ab.
Der Nutzen hängt außerdem davon ab, wie das Team finanziert wird. Bleiben dieselben Beschäftigten im Unternehmen, führt der eingesparte Aufwand möglicherweise zu mehr Kapazität für andere Aufgaben, nicht aber zu einer unmittelbar niedrigeren Rechnung. Einsparungen bei Hosting, Lizenzen und Support sollten separat erfasst werden – einschließlich der Übergangsphase, in der beide Systeme parallel betrieben werden müssen.
Mit besseren Werkzeugen rechnen – und weiter messen
Wir gehen davon aus, dass wiederholbare Modernisierungsarbeiten wirtschaftlicher werden, wenn sich die Werkzeuge verbessern und Teams erprobte Migrationsmuster aufbauen. Beim ersten Projekt muss ein großer Teil des Vorgehens noch entwickelt werden. Spätere Projekte können darauf aufbauen, sofern die Anwendungen ähnliche Technologien und fachliche Anforderungen haben.
Es gibt keinen verlässlichen Prozentsatz, um den die Kosten jedes Jahr sinken werden. Auch bessere Werkzeuge müssen mit den Daten, Entscheidungen und Lieferprozessen des jeweiligen Unternehmens funktionieren. Prüfen Sie die Wirtschaftlichkeit nach jedem Release erneut – insbesondere beim Wechsel der Werkzeuge oder beim Einstieg in einen weniger vertrauten Teil des Systems.
Mit einer Anwendung und einem Geschäftsziel beginnen
Wir bei TechHub Europe empfehlen, mit einer Anwendung und einem klaren Geschäftsziel zu beginnen. Stellen Sie fest, was unbedingt weiter funktionieren muss, erproben Sie das Vorgehen an einem repräsentativen Teil des Systems und nutzen Sie die Ergebnisse für die Planung der nächsten Investition. So entsteht für alle Beteiligten eine belastbarere Grundlage für Gespräche über Kosten, Zeitbedarf und Risiken.
Wenn eine ältere Anwendung zunehmend schwer zu unterstützen ist, schreiben Sie uns an hello@techhub.eu. Gemeinsam können wir klären, wo eine Analyse sinnvoll wäre und welcher Teil des Systems sich als Ausgangspunkt eignet.