Strategien der Legacy-Ablösung

In einer dreiteiligen Artikelserie werde ich verschiedene Aspekte der Legacy Ablösung betrachten. Im ersten Teil geht es um die Strategien auf Ebene eines Unternehmens und der gesamten Anwendungslandschaft. Im zweiten Teil widme ich mich konkreten Taktiken zur Modernisierung einzelner Anwendungen, bevor im dritten Teil mehrere Architekturmuster vorgestellt werden, um ein schrittweises Reengineering von Legacy-Anwendungen im laufenden Betrieb zu ermöglichen.

Strategie Retain - Zurücklehnen und beibehalten

Im Rahmen einer Legacy-Strategie für ein gesamtes Unternehmen mit häufig mehreren Hundert Anwendungen, ist eine Kombination verschiedener Strategien notwendig. Die Strategien sind auch als “5Rs” bekannt, weil alle in der englischen Benennung mit dem Buchstaben R beginnen. Die erste Strategie Retain entspricht dabei der Nullhypothese: Die Legacy-Anwendung bleibt, wie sie ist. Retain bedeutet wörtlich übersetzt “zurückbehalten” und bezeichnet treffend die beiden Aspekte dieser Strategie: zum einen behalten wir die Legacy Anwendung bei, zum anderen stellen wir die langfristige Entscheidung erstmal zurück. Retain ist damit eine Übergangslösung, bis eine andere Strategie benötigt wird und wird eingesetzt für Anwendungen, bei denen kein dringender Handlungsbedarf besteht. Wenn die Entwickler:innen nicht in den nächsten fünf Jahren in Rente gehen, die Technologien vielleicht etwas angestaubt sind, aber noch gewartet und supported werden und die Kunden bezüglich Funktionalität und Benutzbarkeit zufrieden sind, kann die Anwendung mit gutem Gewissen für die nächsten Jahre weiter betrieben werden.

Die Retain-Strategie wirkt damit fast zu trivial, um sie als Strategie zu erwähnen. Aber sie ist eine wichtige Option im Sinne der Priorisierung der IT-Modernisierung eines Unternehmens, da unmöglich alle Anwendungen gleichzeitig modernisiert werden können. Die bewusste Entscheidung, eine Anwendung als Retain zu klassifizieren, schafft Klarheit für Anwender:innen und Entwicklungsteams und erlaubt eine Fokussierung auf die dringenden Modernisierungsthemen.

Strategie Rehost - Lift-and-Shift auf neue Plattformen

Wenn lediglich die Betriebsplattform ausgetauscht wird, spricht man von Rehosting oder im Cloud-Umfeld auch vom Lift-and-Shift. Die Anwendung selbst bleibt dabei unverändert und lediglich die Laufzeitumgebung wird geändert. Die Rehost-Strategie fängt beim Rechenzentrumsumzug oder dem Wechsel der Linux-Distribution an und endet beim Umzug vom IBM Mainframe auf Mainframe-Emulationen in der Cloud.

Die Vorteile dieser Strategie liegen auf der Hand: die Migration ist vermeintlich einfach, schnell und kostengünstig. Aber unter dem Strich bleibt Rehost eine Übergangslösung und stellt keine nachhaltige Modernisierung dar. Die Programmiersprachen, Bibliotheken und Technologien bleiben weitestgehend erhalten und das Know-How in veralteten Programmiersprachen wird damit ebenfalls weiterhin benötigt. Daneben kann ein Plattformwechsel neue Probleme erzeugen, da sich die Betriebsinfrastruktur verändert und bestehende Qualitätseigenschaften wie Stabilität, Performance oder Kosteneffizienz nach der Migration nicht mehr erfüllt sein müssen. Für ein Rehosting sind deshalb umfangreiche Tests der Qualitätseigenschaften notwendig - die wiederum die Aufwände in die Höhe treiben. Darüber hinaus können Potenziale und Vorteile der neuen Plattform selten ausgeschöpft werden. Gerade bei einem Lift-and-Shift in die Cloud bleiben die Vorteile wie elastisches Skalieren, höhere Verfügbarkeit oder eine schnellere Time-to-market meist ungenutzt. Erst durch ein anschließendes umfangreiches Reengineering-Projekt der Anwendungslogik können die Vorteile der Cloud wirklich ausgenutzt werden.

Trotzdem ist diese Strategie in Teilbereichen sehr sinnvoll. Rehosting kann z.B. genutzt werden, um durch den Plattformwechsel zuerst Betriebskosten einzusparen und damit das Reengineering zu finanzieren. Auch bei Standard-Software ist diese Strategie empfehlenswert, da viele Provider wie Microsoft oder Atlassian ihre Anwender in die Cloud migrieren wollen. Die Nachteile fallen für die Nutzer einer Standardsoftware nicht so sehr ins Gewicht, weil sie überwiegend den Provider der Software betreffen.

Aber auch bei Individualsoftware kann die Strategie nutzbringend angewendet werden, wenn die Anwendungen technologisch weitestgehend dem Stand der Technik entsprechen und veraltete oder teure Plattformen abgeschaltet werden. Als Beispiel sei das Rehosting von Java-EE-Anwendungen von on-premise Application Servern auf leichtgewichtige Servlet-Container wie Apache Tomcat in der Cloud genannt.

Strategie Replace - Einen Ersatz schaffen

Bei der Replace-Strategie wird eine bestehende Anwendung vollständig durch eine andere Anwendung ersetzt. Diese Strategie findet häufig beim Kauf von Standardsoftware Anwendung, kann aber auch den Ersatz durch eine Eigenentwicklung bedeuten. Diese Strategie wird auch bei Fusionsprojekten vielfach eingesetzt, um fachliche redundanten Anwendungen der ursprünglichen Unternehmen zu ersetzen und in eine gemeinsame Lösung zu migrieren.

Die Replace-Strategie hat große Vorteile: ein kompletter Neuanfang ist möglich und in die neue Software können alle Anforderungen einfließen, die in der Legacy-Software nicht umgesetzt ist. Durch Replace wird eine dauerhafte und nachhaltige technologische und fachliche Modernisierung erreicht - zumindest so lange, bis auch die neue Software das Legacy-Label verpasst bekommt. Aber die Strategie hat auch große Nachteile: ein Ersatz ist meistens nur vollständig möglich und damit liegt häufig eine Big-Bang-Migration vor, bei der an einem Termin vom alten Anwendungssystem auf das neue System umgeschwenkt wird. Mit einer Big-Bang-Migration geht eine hohe Komplexität und ein hohes Risiko des Scheiterns einher [3]. Aus diesem Grund haben viele Replace-Migrationen eine lange Laufzeit und hohe Kosten.

Falls die Replace-Strategie mit einem kompletten Rewrite einer neuen Software einhergeht, dann spricht man auch von einem Cold-Turkey-Ansatz, angelehnt an den plötzlichen Drogenentzug. Schon Mitte der 1990er Jahre [4] wurde vor diesem Ansatz aufgrund von zehn Impediments gewarnt, die in der Praxis sehr häufig zum Scheitern von Migrationsprojekten im Cold-Turkey-Ansatz führen.

1. Ein besseres System muss versprochen werden.

2. Geschäftsanforderungen bleiben niemals stabil.

3. Spezifikationen sind selten vorhanden.

4. Undokumentierte Abhängigkeiten existieren häufig.

5. Legacy-Systeme könnten zu groß für eine Datenmigration sein.

6. Das Management großer Projekte ist schwierig.

7. Verspätungen werden selten toleriert.

8. Große Projekte werden aufgebläht.

9. Das Gleichgewicht wird beibehalten, der Change vermieden.

10. Die Analyse des umfangreichen Legacy-Systems führt zur Lähmung

Statt Cold Turkey empfehlen die Autoren einen inkrementellen Ansatz namens “Chicken Little”, einem Disney-Charakter, im Deutschen Hühnchen Junior, aus dem Film Himmel und Huhn. Dieser inkrementelle Ansatz macht sich Schnittstellen und Gateways zu Nutze, um schrittweise die Daten und Anwendungen zu migrieren. Dieses Vorgehen entspricht der Reengineering-Strategie.

Strategie Reengineer - Der Goldstandard

Eine wirklich nachhaltige Modernisierung von Anwendungen wird nur durch die Reengineering-Strategie erreicht. Damit wird eine schrittweise technologische Modernisierung und Neuentwicklung bezeichnet. Die Vorgehensweise orientiert sich üblicherweise an den bestehenden fachlichen Komponenten oder technischen Schichten des Legacy-Systems. Reengineering bietet sich insbesondere dann an, wenn nur einige der verwendeten Technologien ausgetauscht werden müssen und die fachliche Logik weitestgehend beibehalten wird. Ein Rearchitecting für die neue Zielplattform ist ebenfalls möglich. Das kann beispielsweise die Nutzung von Cloud-Services bei einer Cloud-Migration oder die Umstellung auf eine Microservice- oder Serverless-Architektur beinhalten.

Vorteile des Reengineering sind das damit verbundene Refactoring. Üblicherweise haben sich bei Legacy-Software viele Baustellen in einem Refactoring-Backlog angesammelt, die mal “angegangen werden müssten”. Im Rahmen des Reengineering können diese Refactorings parallel umgesetzt werden, da insbesondere der Testaufwand dann nur einmalig anfällt. Es kann auch gleichzeitig fachliches Optimierungspotenzial durch den Abbau von Redundanzen oder die Implementierung neuer Features gehoben werden. Und gerade bei der Cloud-Migration hat man die Chance, das Potenzial der neuen Plattform vollständig auszuschöpfen. Der größte Vorteil für mich ist aber das schrittweise Vorgehen. Sprint für Sprint und Release für Release werden einzelne Komponenten reengineered und schrittweise produktiv gesetzt. Damit werden die Risiken einer Big-Bang-Migration vermieden und das Modernisierungsprojekt schafft von Anfang an Mehrwerte für das Business.

Trotzdem ist Reengineering ein komplexes und langwieriges Projekt. Und das schrittweise Reengineering muss parallel zum Tagesgeschäft der Wartung und fachlichen Weiterentwicklung gestemmt werden. In vielen Fällen muss das Entwicklungsteam in der Reengineering-Phase aufgestockt werden, um beide Aspekte gleichzeitig bedienen zu können. Eine gute Empfehlung für das Reengineering besteht darin, die Expert:innen aus beiden Welten (Legacy und Neuentwicklung) zusammenzubringen und am besten gemischte Teams aufzustellen. Idealerweise hat man Menschen im Team, die sowohl im Legacy-Umfeld als auch in der neuen Welt zuhause sind und als Übersetzer zwischen den Welten im Entwicklungsteam fungieren.

Strategie Retire - In den wohlverdienten Ruhestand

Allen Strategien ist gemein, dass die Arbeit damit nicht getan ist: Die Legacy-Anwendung muss schlussendlich in den wohlverdienten Ruhestand geschickt werden. Retire bezeichnet die vollständige Abschaltung der Legacy-Software, nachdem eine der anderen Strategien - hoffentlich - zum Erfolg geführt hat. Erst mit dem Retirement oder auch Decommissioning werden tatsächlich die Kosten für den Betrieb und die Wartung eingespart. Vor der Abschaltung der Altanwendung müssen die fachlichen Daten in das Zielsystem migriert und/oder abhängig von fachlichen Notwendigkeiten und Aufbewahrungsfristen archiviert werden. Auch diese fachliche Datenmigration ist ein eigenständiges Projekt mit hohem Testaufwand für die Migrationsregeln. Die Korrektheit der Migration wird durch fachliche Prüfsummen überprüft, die die Vollständigkeit und die Integrität der Daten im Zielsystem sicherstellen.

Ich habe es schon öfter erlebt, dass dieser letzte Schritt auch der schwerste ist. Das hängt immer wieder damit zusammen, dass die Fachlichkeit durch die neue Anwendung nicht vollständig umgesetzt worden ist und noch eine Restzahl von Verträgen, Konten, Personen oder anderen fachlichen Entitäten in der Legacy-Software verwaltet werden muss. Die letzten 20% sind auch bei der Legacy-Ablösung immer die schwersten und machen teilweise im Sinne des Pareto-Prinzips 80% des Aufwands aus. Aber spätestens wenn die letzte Entwickler:in in Rente geht, wäre man froh auch die Anwendungen mit in den Ruhestand schicken zu können. Denn die Aufwände werden sicherlich stark ansteigen, wenn im Team keiner mehr die Technik des Legacy-Systems oder die Fachlichkeit im Detail versteht.

Die Kombination der Strategien führt zum Erfolg

Wenn man die gesamte Anwendungslandschaft eines größeren Unternehmens betrachtet, ist eine Kombination der verschiedenen Strategien notwendig, um die stetige Modernisierung der Anwendungen sicherzustellen. Die Strategien ergänzen sich sehr gut. Der Replace von Eigenentwicklungen durch Standardsoftware in fachlichen Unterstützungsdomänen wie Personal oder Finanzen schafft Freiräume für die eigene IT-Abteilung, um die marktdifferenzierenden Systeme im Kerngeschäft zu reengineeren. Durch das Rehosting auf leistungsfähigere oder kostengünstigere Plattformen kann man Zeit gewinnen und Investitionsbudgets aufbauen für die Umsetzung einer langfristigeren Strategie. Die Klassifikation Retain einer Teilmenge der Anwendungslandschaft fokussiert das Unternehmen auf die dringendsten Legacy-Ablösungsprojekte. Und durch Retire werden weitere Freiräume bezüglich Personal und Sachkosten geschaffen.

Trotzdem bleibt die keinesfalls einfache Entscheidung für die richtige Strategie für jede einzelne Anwendung zu treffen. Diese konsequente Architekturplanung der Anwendungslandschaft kann für größere Unternehmen im Rahmen eines Enterprise Architecture Management [5] erfolgen, bei dem schrittweise Zielbilder und Bebauungspläne für die einzelnen fachlichen Domänen definiert werden. Die Entscheidung, ob ein Reengineering erfolgsversprechend ist, kann durch Architektur-Reviews vorbereitet werden, bei denen die fachliche und technische Architektur der Anwendung in Bezug auf die fachliche und technische Strategie des Unternehmens bewertet werden.

Bei größeren Modernisierungsprogrammen mit vielen betroffenen Anwendungen lassen sich durch die konzertierte Adressierung von Querschnittsthemen wie der Cloud als Zielplattform, IT-Sicherheit oder Testmanagement Synergien zwischen den einzelnen Migrationsprojekten heben. Die Erfahrungen aus der Anwendung der Strategien lassen sich gewinnbringend für Folgeprojekte einsetzen. Die Herausforderungen bei Legacy-Migrationen sind oft ähnlich, insbesondere wenn es sich um dieselben Quell- oder Zieltechnologien handelt. Auch Stolpersteine wie fehlende Testautomatisierung oder unzureichende Dokumentation sind ein regelmäßiger Begleiter von Modernisierungen und lassen sich in gleicher Weise adressieren.

Wandel braucht Begleitung

Jede erfolgreiche Umsetzung einer der Legacy-Strategien bedeutet eine große Veränderung für die betroffenen Personen. Deswegen ist es unerlässlich, dass die Modernisierung durch ein Change Management oder Transition Management [6] begleitet wird. Entwickler:innen, die seit zehn oder vielleicht 20 Jahren an den Anwendungen arbeiten, haben es verdient, auf dem schwierigen Weg der Ablösung begleitet und unterstützt zu werden. Für einige Mitarbeitende wird sich das Arbeitsumfeld verändern, die Kolleg:innen werden wechseln und nicht selten geht die Ablösung der Anwendung, für die man vorher Experte war, mit einem Bedeutungsverlust für die Mitarbeitenden einher. Ein wertschätzender Umgang mit den Betroffenen, die so lange den erfolgreichen Geschäftsbetrieb des Unternehmens mit ihren Anwendungen gesichert haben, ist besonders wichtig für den Erfolg der Modernisierung.

Change Management ist eine Disziplin für sich, deswegen an dieser Stelle nur ein Tipp: Feiert die Abschaltung eines Legacy-Systems, wenn der Moment gekommen ist und gebt dem System einen würdigen Abschied. Bietet den Mitarbeitenden, die einen Großteil ihres Berufslebens für dieses System gearbeitet haben, einen würdigen Rahmen, sich angemessen vom System zu verabschieden. Und vergesst nicht, ihre Verdienste für das Unternehmen zu würdigen.

Dieser Blogpost wurde zuerst als Artikel im Java Magazin 8/2025 veröffentlicht: https://app.entwickler.de/gEMYrJsUgUb

Links und Literatur

[1] Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz: Object-Oriented Reengineering Patterns, Object-Oriented Reengineering Patterns

[2] Brian Foote, Joseph Yoder: Big Ball of Mud, http://www.laputan.org/mud/

[3] "Elwis" ist tot: Lidl stoppt millionenschweres Projekt mit SAP

[4] Michael L. Brodie, Michael Stonebraker: Migrating Legacy Systems, Morgan Kaufmann, San Francisco 1995.

[5] Inge Hanschke: Enterprise Architecture Management - einfach und effektik, Hanser, München, 2022.

[6] William Bridges, Susan Bridges: Managing Transitions - Making the Most of Change, Balance, 2017.