Legacy Software ist häufig gleichzeitig Problem und Vermögenswert. Sie basiert vielleicht auf älteren Technologien, enthält aber Geschäftslogik, Daten und Abläufe, die über Jahre gewachsen sind und täglich funktionieren.
Deshalb ist „alt“ allein kein ausreichender Grund für einen Rewrite. Eine Modernisierung sollte zuerst klären, welcher Teil der Anwendung tatsächlich zum Risiko geworden ist.
Legacy Software modernisieren heißt nicht, Vergangenheit zu löschen. Es heißt, technische Grenzen so abzubauen, dass die Anwendung wieder sicher veränderbar wird.
Was ist Legacy Software?
Der Begriff wird häufig für Software verwendet, die bereits lange im Einsatz ist und durch veraltete Technologien, Architekturen oder technische Schulden schwerer wartbar wird.
- Frameworks oder Laufzeiten sind veraltet.
- Updates werden aus Angst vor Seiteneffekten vermieden.
- Dokumentation ist lückenhaft.
- Tests fehlen.
- Deployments sind manuell oder personengebunden.
- Integrationen sind schwer zu erweitern.
- Neue Funktionen benötigen unverhältnismäßig viel Aufwand.
IBM beschreibt Legacy-Modernisierung als Aufwertung oder Transformation älterer Anwendungen in anpassungsfähigere Lösungen. Dabei spielen technische Schulden und die Fähigkeit, zukünftige Anforderungen umzusetzen, eine zentrale Rolle.
Nicht jedes alte System ist automatisch schlecht
Eine Anwendung kann zehn Jahre alt und trotzdem fachlich wertvoll, stabil und gut strukturiert sein. Gleichzeitig kann eine drei Jahre alte Anwendung bereits schwer wartbar sein, wenn sie unter hohem Zeitdruck ohne Tests und klare Architektur entstanden ist.
Für eine Modernisierungsentscheidung sind deshalb vier Fragen relevanter als das Alter:
- Wie geschäftskritisch ist die Anwendung?
- Wie gut lässt sie sich verändern?
- Welche technischen Risiken bestehen?
- Welche zukünftigen Anforderungen blockiert sie?
Die wichtigsten Modernisierungsstrategien
1. Beibehalten
Wenn ein System stabil funktioniert, kaum verändert werden muss und keine kritischen Sicherheits- oder Betriebsrisiken besitzt, kann bewusst entschieden werden, es zunächst weiter zu betreiben.
2. Rehosting
Beim Rehosting wird die Anwendung in eine neue Infrastruktur verschoben, ohne die eigentliche Anwendung wesentlich zu verändern. AWS beschreibt diesen Ansatz auch als „Lift and Shift“.
Das kann sinnvoll sein, wenn beispielsweise ein alter Server abgelöst werden muss, aber kurzfristig keine Ressourcen für eine tiefere Modernisierung vorhanden sind.
3. Replatforming
Beim Replatforming wird nicht nur der Betriebsort verändert, sondern auch ein Teil der Plattform modernisiert, etwa durch Container oder stärker verwaltete Infrastruktur.
4. Refactoring
Refactoring verändert die interne Struktur des Codes, ohne das fachliche Verhalten grundsätzlich zu ändern.
- stärkere Modulgrenzen,
- bessere Testbarkeit,
- weniger Duplikate,
- aktualisierte Abhängigkeiten,
- leichtere Erweiterbarkeit.
5. Schrittweise Ablösung
Wenn Teile des Systems ersetzt werden müssen, kann eine schrittweise Modernisierung sinnvoller sein als ein vollständiger Rewrite.
Das Strangler-Fig-Muster beschreibt einen solchen Weg: Neue Funktionen oder Teilbereiche entstehen neben dem bestehenden System. Alte Komponenten werden nach und nach ersetzt, während der produktive Betrieb weiterläuft.
Ein altes Kundenportal besitzt eine schwer wartbare Oberfläche, aber eine funktionierende Geschäftslogik. Statt das gesamte System neu zu bauen, kann zunächst eine neue Benutzeroberfläche oder ein neues Teilmodul vor die bestehende Logik gesetzt werden. Weitere Teile folgen schrittweise.
6. Kompletter Rewrite
Ein Neubau kann richtig sein, wenn Architektur und Technologien zentrale Geschäftsanforderungen dauerhaft blockieren oder eine kontrollierte Weiterentwicklung nicht mehr wirtschaftlich ist.
Ein Rewrite sollte aber nicht mit der Annahme beginnen, dass die alte Software wertlos ist. Die fachliche Logik muss trotzdem vollständig verstanden werden.
Warum Big-Bang-Rewrites riskant sind
Ein kompletter Neubau verspricht einen sauberen technischen Neustart. Gleichzeitig entsteht eine lange Phase, in der zwei Realitäten nebeneinander existieren: das alte System, das täglich genutzt wird, und das neue System, das noch nicht alle Funktionen besitzt.
- versteckte Geschäftsregeln werden erst spät entdeckt,
- Datenmigration wird unterschätzt,
- Integrationen sind komplexer als dokumentiert,
- Nutzeranforderungen verändern sich während des Neubaus,
- das alte System muss parallel weiter gepflegt werden.
Martin Fowler beschreibt schrittweise Ablösungsansätze gerade deshalb als Alternative zu großen Rewrite-Projekten.
Ein sinnvolles Vorgehen zur Legacy-Modernisierung
Schritt 1: Geschäftsrelevanz verstehen
Welche Prozesse hängen an der Anwendung? Welche Ausfälle wären kritisch? Welche Funktionen werden tatsächlich genutzt? Diese Fragen verhindern, dass technische Modernisierung zum Selbstzweck wird.
Schritt 2: Technische Bestandsaufnahme
- Repository und Versionsstand
- Programmiersprachen und Frameworks
- Dependencies
- Datenbank
- Tests
- Build und Deployment
- Hosting
- Schnittstellen
- Authentifizierung und Rollen
- bekannte Bugs
- Dokumentation
Schritt 3: Problemzonen statt Gesamtgröße bewerten
Nicht jede Zeile alten Codes muss modernisiert werden. Relevant sind vor allem Bereiche, die zukünftige Änderungen, Sicherheit oder Betrieb beeinträchtigen.
Schritt 4: Zielarchitektur und Übergang planen
Ein Zielbild sollte nicht nur beschreiben, wie die neue Technik aussehen soll. Es muss auch erklären, wie das Unternehmen vom heutigen Zustand dorthin kommt.
- Reihenfolge der Teilbereiche
- Datenmigration
- Parallelbetrieb
- Rückfalloptionen
- Schnittstellen zwischen Alt und Neu
- Abschaltkriterien für alte Komponenten
Schritt 5: Einen ersten wertvollen Teil modernisieren
Ein sinnvoller erster Bereich ist klein genug, um Risiko zu kontrollieren, aber relevant genug, um den neuen Ansatz praktisch zu testen.
Schritt 6: Anhand realer Nutzung fortsetzen
Nach dem ersten produktiven Teil kann entschieden werden, welche Komponente als Nächstes folgt. So entsteht schrittweise eine modernere Anwendung, ohne den gesamten Nutzen erst an das Projektende zu verschieben.
Welche Rolle technische Schulden spielen
Technische Schulden sind kein Argument dafür, jede Altanwendung zu ersetzen. Sie sollten vielmehr sichtbar gemacht und priorisiert werden.
Hohe Priorität: Sicherheitsrisiko, nicht unterstützte Runtime, blockierende Architektur, instabile Releases.
Niedrigere Priorität: unschöne interne Struktur in einem Bereich, der selten verändert wird und zuverlässig funktioniert.
Modernisierung ist auch Organisationsarbeit
Technische Veränderungen wirken auf Mitarbeitende, Prozesse und Verantwortlichkeiten. Eine neue Plattform löst deshalb nicht automatisch organisatorische Probleme.
Vor allem bei geschäftskritischen Anwendungen sollten Nutzer und fachliche Verantwortliche früh einbezogen werden. Sie kennen Sonderfälle, die im Code möglicherweise nirgends erklärt werden.
Fazit
Legacy Software zu modernisieren bedeutet nicht automatisch, sie vollständig neu zu schreiben. Zwischen Weiterbetrieb und Rewrite liegen mehrere sinnvolle Strategien.
Die beste Variante hängt davon ab, welche Teile heute tatsächlich Risiken verursachen und welche Geschäftsfunktionen unbedingt erhalten bleiben müssen.
Häufige Fragen
Was ist Legacy Software?
Als Legacy Software werden meist länger eingesetzte Anwendungen bezeichnet, deren Technologien, Architektur oder technische Schulden Wartung und Weiterentwicklung zunehmend erschweren.
Muss Legacy Software komplett neu entwickelt werden?
Nein. Je nach Ausgangslage sind auch Weiterbetrieb, Rehosting, Replatforming, Refactoring oder eine schrittweise Ablösung einzelner Komponenten möglich.
Was ist das Strangler-Fig-Muster?
Dabei werden Teile eines bestehenden Systems schrittweise durch neue Komponenten ersetzt, während das Altsystem zunächst weiterläuft.
Wann ist ein Rewrite sinnvoll?
Ein kompletter Neubau kann sinnvoll sein, wenn die technische Basis zentrale Anforderungen blockiert, nicht mehr sicher betrieben werden kann oder eine Weiterentwicklung wirtschaftlich nicht mehr vertretbar ist.