3.6 Legacy-Modernisierung

Überblick und Motivation

Legacy-Systeme sind die Systeme, die die Welt betreiben. Die Kernbank-Kontobücher, Steuer- und Leistungs-Engines, Flugverkehrs- und Verteidigungssysteme, Versicherungspolicenverwaltung, und Behördenregister, auf die sich Gesellschaften verlassen, sind häufig Jahrzehnte alt. Viele sind in COBOL (Common Business-Oriented Language) oder anderen älteren Technologien geschrieben, und sie verarbeiten immer noch die Mehrheit kritischer Transaktionen. “Legacy” ist keine Beleidigung. Es bedeutet, dass das System wertvoll genug ist, überlebt zu haben, kritisch genug, dass Scheitern katastrophal ist, und alt genug, dass es sicher zu ändern schwer ist. Legacy-Modernisierung ist die Disziplin, diese Systeme zu verbessern, migrieren, oder ersetzen, ohne die essenziellen Dienste zu brechen, die sie bieten.

Das ist unverhältnismäßig ein Unternehmens- und Behördenproblem, und es ist, wo die größten, öffentlichsten IT-Scheitern auftreten. Ein riesiger Anteil größerer Transaktionen weltweit berührt immer noch Großrechner-Systeme. Ein großer Bruchteil des Produktionscodes in großen Institutionen ist in älteren Sprachen, gepflegt von einem alternden, schrumpfenden Pool von Spezialistinnen. Behörden tragen die schwerste Last: gesetzliche Pflichten, über Jahrzehnte kodiert, Beschaffungs- und Budgetzyklen, die Regierungen überleben, und Bürgerdienste, die nicht unterbrochen werden können. Das dominante Risiko ist nicht, dass diese Systeme alt sind, denn viele laufen hervorragend. Es ist, dass das Wissen, sie zu pflegen, in Rente geht, die Plattformen zunehmend teuer und beschränkt sind, und die Versuchung, “es einfach umzuschreiben”, zu einigen der teuersten Scheitern in der Geschichte des Feldes führt.

Dieses Kapitel deckt die inkrementellen Modernisierungsmuster ab, die tatsächlich funktionieren (Würgefeige und Zweig-durch-Abstraktion), wie Legacy-Risiko bewertet und priorisiert wird, die Betreuung von Großrechner- und COBOL-Beständen, die Disziplin Datenmigration und Dual-Running, und vor allem, wie man der Große-Umschreibung-Versuchung widersteht. Die zentrale Überzeugung ist, dass erfolgreiche Modernisierung fast immer inkrementell, beleggetrieben, und kontinuierlich Wert liefernd ist. Sie ist nie ein Mehrjahres-Big-Bang.

Kernprinzipien

Legacy bedeutet wertvoll und grundlegend, nicht bloß alt. Respektieren Sie, was das System tut, bevor Sie es anfassen; es kodiert Jahrzehnte hart erkämpfter Geschäftsregeln.
Inkrementell schlägt Big-Bang, fast immer. Ersetzen Sie Stück für Stück hinter einer stabilen Schnittstelle; liefern Sie kontinuierlich Wert und halten Sie Risiko klein.
Die große Umschreibung ist der Standard-Scheitermodus. Vollständige Umschreibungen überschreiten routinemäßig, liefern zu wenig, und werden abgebrochen; behandeln Sie den Drang mit tiefem Misstrauen.
Sie können nicht modernisieren, was Sie nicht verstehen. Reverse-Engineeren und dokumentieren Sie Verhalten (einschließlich undokumentierter Regeln), bevor Sie es ersetzen.
Datenmigration ist, wo Projekte sterben. Die Daten sind älter, schmutziger, und verwobener als irgendjemand erwartet; planen Sie dafür als erstklassigen Aufwand.
Betreiben Sie alt und neu parallel, um Vertrauen aufzubauen. Dual-Running und Vergleich erwischen Diskrepanzen vor dem Umschalten.
Priorisieren Sie nach Risiko und Wert, nicht nach Alter. Modernisieren Sie zuerst, was am riskantesten und wertvollsten ist, nicht was schlicht am ältesten ist.
Halten Sie die Lichter an, während Sie den Motor wechseln. Der Dienst muss durchgehend weiterlaufen; es gibt keine akzeptable Ausfallzeit für kritische Bürger- oder Finanzsysteme.

Empfehlungen

Inkrementell mit dem Würgefeige-Muster modernisieren

Die Würgefeige (benannt nach der Ranke, die um einen Baum wächst und ihn schrittweise ersetzt) ist das Arbeitspferd sicherer Modernisierung. Setzen Sie eine Routing-Schicht (ein API-Gateway, eine Fassade, oder einen Proxy) vor das Legacy-System. Dann, Fähigkeit für Fähigkeit, bauen Sie den Ersatz in einem modernen System und leiten Sie diese Verkehrsscheibe dorthin um, den Rest auf dem Legacy-System lassend. Über Zeit wächst das neue System und das alte schrumpft, bis es pensioniert werden kann. Das liefert kontinuierlich Wert, hält jede Änderung klein und umkehrbar, vermeidet ein riskantes Umschalten, und lässt Sie an jedem Punkt stoppen oder neu priorisieren. Es ist das Gegenteil des Big Bangs. Das Legacy-System läuft weiter und verdient sich weiter seinen Platz, während Sie es darum herum ersetzen.

Zweig-durch-Abstraktion für interne Nähte nutzen

Wo Sie eine Komponente ersetzen müssen, von der viele Teile des Systems abhängen, nutzen Sie Zweig-durch-Abstraktion. Führen Sie eine Abstraktionsschicht (eine Schnittstelle) über die bestehende Implementierung ein, migrieren Sie Aufruferinnen, von der Abstraktion abzuhängen, bauen Sie die neue Implementierung hinter derselben Abstraktion, schalten Sie um (oft hinter einem Feature-Flag, schrittweise), und entfernen Sie schließlich die alte Implementierung. Das lässt eine große Komponente inkrementell auf der Hauptentwicklungslinie ersetzt werden, ohne einen langlebigen Zweig, das System durchgehend veröffentlichbar haltend. Es paart sich natürlich mit der Würgefeige: die Fassade handhabt externe Nähte, Zweig-durch-Abstraktion handhabt interne.

Legacy-Risiko absichtlich bewerten und priorisieren

Bevor Sie modernisieren, bauen Sie ein klarsichtiges Inventar und eine Risikobewertung des Bestands. Für jedes System bewerten Sie es nach Geschäftskritikalität, technischem Risiko (Veralten, nicht unterstützte Plattformen, Sicherheitsexposition), Änderungshäufigkeit, und, entscheidend, Wissensrisiko (wie viele Menschen es noch pflegen können, und wie nah sie an der Rente sind). Zeichnen Sie Systeme auf einem Risiko-versus-Wert-Raster ein. Priorisieren Sie, zu modernisieren, was sowohl hochriskant als auch hochwertig ist. Erwägen Sie, stabile, änderungsarme, gut verstandene Systeme in Ruhe zu lassen, selbst wenn sie alt sind, denn ein funktionierendes System, das niemand ändern muss, ist kein Notfall. Diese Bewertung verwandelt “alles ist alt und beängstigend” in eine verteidigbare, sequenzierte Roadmap.

Den Großrechner- und COBOL-Bestand betreuen, nicht nur ersetzen

Nicht jedes Großrechner- oder COBOL-System sollte, oder kann sicher, bald ersetzt werden. Die kurzfristige Priorität ist oft Betreuung: das Wissen erfassen, bevor es in Rente geht. Dokumentieren Sie die Geschäftsregeln, die der Code kodiert (viel davon undokumentiert und unersetzbar), investieren Sie in automatisierte Tests, die aktuelles Verhalten festnageln, damit zukünftige Änderung sicher ist, rekrutieren und kreuztrainieren Sie Betreuerinnen, und modernisieren Sie die umgebenden Lieferpraktiken (Quellkontrolle, kontinuierliche Integration (CI), automatisiertes Testen), selbst während der Kern an Ort bleibt. Wo Sie modernisieren, bevorzugen Sie, Legacy-Fähigkeiten durch moderne APIs (Kapselung) als ersten Schritt offenzulegen. Behandeln Sie automatisierte COBOL-zu-moderne-Sprache-Übersetzung mit Vorsicht, denn sie produziert Code, der läuft, aber oft unverständliche Logik treu reproduziert. Die knappste Ressource ist Verständnis, nicht Rechenleistung.

Datenmigration und Dual-Running als Kern des Projekts behandeln

Der schwierigste und riskanteste Teil der meisten Modernisierungsbemühungen sind die Daten. Sie sind voluminös, von schlechter und uneinheitlicher Qualität, und voller undokumentierter Bedeutung, über Jahrzehnte angehäuft. Profilieren und bereinigen Sie sie, bilden Sie alte auf neue Schemas explizit ab, und bauen Sie wiederholbare, automatisierte Migration mit voller Abstimmung (Zählungen, Prüfsummen, Geschäftstotal), damit Sie beweisen können, dass nichts verloren oder verändert wurde. Entrisikieren Sie das Umschalten mit Dual-Running (paralleles Laufen): betreiben Sie das alte und neue System Seite an Seite auf denselben Eingaben und vergleichen Sie Ausgaben, bis das neue System dem alten bis zu Ihrer Vertrauensschwelle entspricht. Erst dann schalten Sie um, und behalten Sie die Fähigkeit, zurückzurollen. Für wirklich kritische Systeme migrieren und schalten Sie in Scheiben um statt alles auf einmal.

Die Große-Umschreibung-Versuchung verwalten

Der Instinkt, das unordentliche alte System wegzuwerfen und ein sauberes neues von Grund auf zu bauen, ist mächtig, und er ist fast immer falsch für große, kritische Systeme. Vollständige Umschreibungen unterschätzen den Wert, versteckt im “hässlichen” Code (Randfälle, regulatorische Regeln, bug-kompatible Verhalten, von denen echte Nutzerinnen abhängen), dauern weit länger als projiziert, liefern keinen Wert bis zum Ende, und werden häufig nach enormen Ausgaben abgebrochen. Neigen Sie standardmäßig zu inkrementeller Modernisierung. Reservieren Sie Umschreibungen für Fälle, wo die Plattform wirklich untragbar ist und inkrementelle Pfade erschöpft sind. Selbst dann zerlegen Sie die Umschreibung in unabhängig lieferbare Stücke via das Würgefeige-Muster statt einer einzelnen Big-Bang-Veröffentlichung. Wenn die Führung auf eine totale Umschreibung drängt, bestehen Sie auf der Frage: welcher Wert liefert in den ersten drei Monaten, und was geschieht, wenn das Programm auf halbem Weg gestoppt wird?

Abwägungen: Vor- und Nachteile

Ansatz	Vorteile	Nachteile
Würgefeige (inkrementell)	Kontinuierlicher Wert, niedriges Risiko, umkehrbar, hält Dienst laufend	Längerer Gesamtzeitplan, muss zwei Systeme parallel betreiben, Integrationsaufwand
Big-Bang-Umschreibung	Reines Blatt, keine Legacy-Beschränkungen im neuen Code	Sehr hohe Scheiterrate, kein Wert bis zum Ende, riesige Kosten, Geschäftsregeln verloren
Kapseln (mit APIs umwickeln)	Schnell, niedriges Risiko, modernisiert Zugriff ohne Kern zu berühren	Kern bleibt Legacy; verschiebt, löst nicht, das zugrunde liegende Risiko
So lassen (betreuen)	Kein Projektrisiko; günstigst kurzfristig	Wissens- und Plattformrisiko häufen sich weiter an; schließliche erzwungene Aktion

Der fundamentale Kompromiss ist Geschwindigkeit der Transformation gegen Scheiterrisiko, und Legacy-Modernisierung ist die Domäne, wo dieser Tausch am schiefsten ist. Die “schnelle, saubere” Big-Bang-Umschreibung ist eine Fata Morgana, die wiederholt das langsamste und teuerste Ergebnis von allen produziert: ein abgebrochenes Programm und ein noch unmodernisiertes System. Inkrementelle Ansätze fühlen sich langsamer an und verlangen, zwei Systeme parallel zu betreiben, aber sie liefern durchgehend Wert, halten Risiko klein und umkehrbar, und sind der empirisch verlässliche Pfad. Der echte Urteilsruf ist zwischen einem stabilen Legacy-System noch eine Weile zu betreuen und inkrementellen Ersatz jetzt zu beginnen. Lassen Sie die Risikotrajektorie diesen Ruf treiben, besonders Wissensrisiko, statt Unbehagen mit alter Technologie.

Fragen zur Diskussion mit Ihrem Team

Haben Sie einen Ort, eine Routing-Schicht vor Ihr Legacy-System zu setzen, und wenn nicht, was würde es brauchen, einen zu erschaffen? Die Würgefeige hängt von einer Naht ab: einem API-Gateway, einer Fassade, oder einem Proxy, durch den Sie eine Fähigkeit nach der anderen zu einer neuen Implementierung umleiten können. Viele alte Systeme haben keine solche Naht, das erste Modernisierungsinkrement ist also oft einfach der Bau des Abfangpunkts, und diese Arbeit ist leicht zu unterschätzen. Bringen Sie die aktuelle Integrationskarte und fragen Sie, wo Verkehr pro Fähigkeit ohne ein Big-Bang-Umschalten abgefangen werden könnte. Wenn es nirgendwo gibt, mag Zweig-durch-Abstraktion auf einer internen Naht stattdessen der Startzug sein. Ohne eine Routing-Schicht haben Sie keinen inkrementellen Pfad, was genau ist, wie Organisationen zurück zur Umschreibung gedrängt werden, die normalerweise scheitert.
Haben Sie Ihren Bestand tatsächlich auf ein Risiko-versus-Wert-Raster eingezeichnet, oder wird Ihre Roadmap davon getrieben, welches System am ältesten wirkt? Das Kapitel besteht darauf, dass Sie zuerst modernisieren, was hochriskant und hochwertig ist, und absichtlich stabile, änderungsarme, gut verstandene Systeme in Ruhe lassen, selbst wenn sie uralt sind. Ohne ein explizites Raster fließt Aufmerksamkeit zur lautesten Beschwerde oder der unmodischsten Technologie, und echte Zeitbomben (ein kritisches System mit zwei Betreuerinnen nahe der Rente) warten. Bewerten Sie jedes System nach Geschäftskritikalität, technischem Risiko, Änderungshäufigkeit, und Wissensrisiko, sequenzieren Sie dann von der oberen rechten Ecke. Bringen Sie dieses Raster zum Meeting als geteilte Karte. Wissensrisiko verdient das schwerste Gewicht, denn es ist der eine Input, der sich nur verschlechtert und nicht zurückgekauft werden kann, sobald die Menschen gehen.
Wenn Sie umschalten, wie werden Sie beweisen, dass kein einziger Datensatz verloren oder verändert wurde, und wer zeichnet diesen Beleg ab? Datenmigration ist, wo diese Projekte sterben, und Vertrauen kommt von Abstimmung: Zeilenzählungen, Prüfsummen, und Geschäftskontrollsummen, die zwischen alt und neu übereinstimmen, plus Dual-Running, das Ausgaben auf denselben Eingaben vergleicht, bis sie zu einer hohen Schwelle übereinstimmen. Für ein Leistungs- oder Kontobuchsystem ist eine Diskrepanz eine unterbezahlte Bürgerin oder ein verlorener Cent, der Beleg muss also eine Prüferin zufriedenstellen, nicht nur eine Ingenieurin. Entscheiden Sie jetzt, welche Summen Sie abstimmen, welche Vertrauensschwelle Umschalten auslöst, und wie lange Sie alt und neu parallel laufen lassen. Behalten Sie Rückroll durchgehend verfügbar, und schalten Sie in Scheiben um statt alles auf einmal. Die Diskrepanzen, die Sie während Dual-Running finden, sind normalerweise undokumentierte Legacy-Regeln, die Sie bewahren müssen, behandeln Sie jede also als Entdeckung, nicht nur als Defekt.
Welche Ihrer Legacy-Systeme betreuen Sie versus aktiv ersetzen, und wer entschied, welches welches ist? Das Kapitel zieht eine absichtliche Linie zwischen Systemen, die es wert sind, an Ort stabilisiert zu werden (Regeln dokumentieren, Charakterisierungstests hinzufügen, Betreuerinnen kreuztrainieren), und Systemen, die es wert sind, inkrementell ersetzt zu werden, und die zwei verlangen sehr unterschiedliche Finanzierung und Besetzung. Für eine große Organisation ist die Gefahr Abdrift: ein System, etikettiert “vorerst betreuen”, wird still “für immer betreuen”, bis die letzte Betreuerin in Rente geht und die Wahl unter Krise für Sie getroffen wird. Die konkurrierenden Erwägungen sind Betreuungskosten und Plattformveralten auf einer Seite gegen das Risiko und die Störung des Ersatzes auf der anderen, und Wissensrisiko sollte die Waage kippen, denn es verschlechtert sich nur. Bringen Sie das Risiko-versus-Wert-Raster, die Betreuerinnen-Personalzahl und den Rentenhorizont für jedes System, und eine explizite Besitzerin für die Betreuen-oder-Ersetzen-Entscheidung. In Unternehmens- und Behördenbeständen benennen Sie einen Prüftakt und eine verantwortliche Beamtin für jedes System, denn eine Klassifizierung, die niemand überprüft, ist eine Entscheidung, die niemand trifft.
Wenn die Führung nach einer vollständigen Umschreibung fragt, was ist Ihre stehende Antwort, und können Sie zeigen, was ein inkrementeller Pfad in den ersten drei Monaten liefert? Die Big-Bang-Umschreibung ist der Standard-Scheitermodus, doch sie wird weiter finanziert, weil ein reines Blatt leicht zu verkaufen ist und eine Würgefeige nicht. Ein großes Team braucht eine geprobte Antwort, damit das Argument auf Beleg gewonnen wird statt darauf, wer am ranghöchsten im Raum ist. Die echte Spannung ist, dass manche Plattformen wirklich untragbar sind und eine Umschreibung gerechtfertigt ist, die Antwort kann also keine pauschale Weigerung sein: sie muss abwägen, ob inkrementelle Nähte noch existieren gegen die echten Kosten, die alte Plattform am Leben zu halten. Bringen Sie den Wert, den ein inkrementelles erstes Inkrement liefern würde, die historische Scheiterrate vergleichbarer Umschreibungen, und eine Zerlegung jeder vorgeschlagenen Umschreibung in unabhängig auslieferbare Stücke. In Behörden, wo ein abgebrochenes Mehrjahresprogramm öffentliches Geld in voller Sicht verbrennt, bestehen Sie darauf, dass jede Umschreibung früh Wert liefert und überlebt, auf halbem Weg gestoppt zu werden, ohne Totalverlust.
Wie werden Sie die Geschäftsregeln erfassen, gesperrt in Ihrem ältesten Code, bevor die Menschen, die sie verstehen, weg sind? Viel vom Wert in einem Legacy-System ist undokumentiertes Verhalten, das Jahrzehnte von Randfällen, Regulierungen, und bug-kompatiblen Korrekturen angehäuft haben, und es lebt in einem schrumpfenden Pool in Rente gehender Spezialistinnen statt in irgendeiner geschriebenen Aufzeichnung. Für eine große Organisation ist das das eine Risiko, das nicht zurückgekauft werden kann, sobald die Menschen gehen, es verdient sich also Finanzierung vor der sichtbareren Plattformarbeit. Der konkurrierende Zug ist, dass Wissenserfassung (Dokumentation, Charakterisierungstests, Reverse-Engineering, Kreuztraining) sich wie Overhead anfühlt, der nichts liefert, was genau ist, warum sie aufgeschoben wird. Bringen Sie ein Inventar, wer kritisches Wissen hält, wie nah sie am Gehen sind, und welche Testabdeckung aktuelles Verhalten heute festnagelt. In regulierten und öffentlichen Umgebungen behandeln Sie die gesetzlichen Regeln, kodiert in altem Code, als Compliance-Vermögenswert: sie still zu verlieren ist keine technische Schuld, es ist eine rechtliche Exposition.

Branchenperspektive

Startup. Ihr Legacy ist Ihr eigenes hastiges MVP, kein Großrechner: ein Prototyp, der jetzt Umsatz trägt und den jeder zu berühren fürchtet. Schreiben Sie ihn nicht um. Wickeln Sie das gruseligste Modul hinter eine saubere Schnittstelle, fügen Sie Charakterisierungstests hinzu, um sein Verhalten festzunageln, und schnitzen Sie Funktionalität inkrementell heraus, damit jede kleine Veröffentlichung Wert liefert und das Risiko schrumpft. Sie haben keine Zeit für einen Von-Grund-auf-Wiederaufbau, Optionalität zählt also mehr als Eleganz.

Kleinunternehmen. Sie haben kein Modernisierungsteam und ein knappes Budget, der praktische Zug ist also normalerweise, ein funktionierendes System funktionierend zu halten: erfassen Sie, was die eine Person, die es versteht, weiß, bringen Sie es in Quellkontrolle mit ein paar automatisierten Tests, und stützen Sie sich auf einen Anbieter oder ein verpacktes Produkt statt eines maßgeschneiderten Wiederaufbaus. Formulieren Sie die Entscheidung als Kaufen versus Bauen, und bevorzugen Sie Kaufen, wenn die Fähigkeit eine Handelsware ist. Verbringen Sie Ihren begrenzten Aufwand auf das eine System, dessen Scheitern das Geschäft stoppen würde, nicht auf was auch immer schlicht am ältesten aussieht.

Großunternehmen. Das Problem ist Portfolio-Maßstab: Dutzende Systeme, viele Teams, und bestandsweites Wissensrisiko. Führen Sie eine geteilte Risiko-versus-Wert-Bewertung durch, standardisieren Sie auf inkrementelle Muster (Würgefeige und Zweig-durch-Abstraktion), und behandeln Sie Datenmigration und Dual-Running als erstklassige Disziplinen mit Abstimmung, der jeder vertraut. Regieren Sie Modernisierung als kontinuierliches Portfolio gegen Risikotrajektorie statt eines Durcheinanders heldenhafter Projekte, und budgetieren Sie Betreuung und Wissenserfassung explizit, damit kein kritisches System von einer einzelnen in Rente gehenden Betreuerin abhängt.

Behörde. Gesetzliche Pflichten, über Jahrzehnte kodiert, Beschaffungsregeln, und Bürgerdienste, die nicht unterbrochen werden können, machen Big-Bang-Ersatz besonders gefährlich. Bevorzugen Sie inkrementelle Würgefeige-Migration mit Scheibe-für-Scheibe-Umschalten, beweisen Sie durch Abstimmung und langes paralleles Laufen, dass kein einziger Bürgerdatensatz verloren oder falsch berechnet wurde, und behalten Sie Rückroll durchgehend verfügbar. Beschaffung sollte Datenportabilität und Offenlegung von Geschäftsregeln verlangen statt undurchsichtiger Übersetzung, und jedes Mehrjahresprogramm muss früh prüfbaren Wert liefern und öffentliche Prüfung überleben, wenn es auf halbem Weg gestoppt wird.

Beispiele

Startup. Das ursprüngliche MVP eines dreijährigen Startups ist zu seiner eigenen Art Legacy geworden: ein überstürzter Prototyp, der jetzt echten Umsatz handhabt und den jeder zu berühren fürchtet. Statt einer Umschreibung wickelt das Team das schlimmste Modul hinter eine saubere Schnittstelle, fügt Charakterisierungstests hinzu, um sein aktuelles Verhalten festzunageln, und verschiebt Funktionalität stückweise über ein paar Monate heraus. Jede kleine Veröffentlichung liefert Wert und schrumpft den gruseligen Teil, sodass das Startup ein pflegbares System bekommt, ohne das Unternehmen auf einen Von-Grund-auf-Wiederaufbau zu setzen, den es sich nicht leisten kann.

Großunternehmen. Ein großer Versicherer betreibt Policenverwaltung auf einem Großrechner-COBOL-System, das verlässlich, aber teuer zu ändern ist und von einer Handvoll Ingenieurinnen nahe der Rente gepflegt wird. Statt einer Umschreibung wickelt der Versicherer den Großrechner mit modernen APIs und wendet die Würgefeige an: neue Angebot-und-Kauf- und Selbstbedienungsfähigkeiten werden auf einer modernen Plattform gebaut und durch eine Fassade geroutet, während Kern-Policendatensätze auf dem Großrechner bleiben. Parallel dokumentiert das Team Geschäftsregeln und fügt Charakterisierungstests um das COBOL hinzu. Über mehrere Jahre zieht Fähigkeit für Fähigkeit vom Großrechner weg, jede Veröffentlichung Wert liefernd, bis der verbleibende Kern zu den Bedingungen des Versicherers pensioniert werden kann statt unter Krise.

Behörde. Eine Sozialversicherungsbehörde muss ein jahrzehntealtes Leistungsberechnungssystem modernisieren, das Millionen Bürgerinnen bezahlt und nicht unterbrochen oder falsch bezahlt werden kann. Sie lehnt einen Big-Bang-Ersatz ab, nachdem sie vergleichbare gescheiterte Programme studiert hat. Stattdessen profiliert und bereinigt sie die Daten, baut automatisierte Migration mit voller Abstimmung gegen Kontrollsummen, und betreibt die neue Leistungs-Engine parallel zur alten für viele Monate, beide mit denselben Ansprüchen fütternd und jede Berechnung vergleichend, jede Diskrepanz untersuchend (oft undokumentierte Legacy-Regeln aufdeckend, die bewahrt werden müssen). Erst sobald das neue System dem alten zu sehr hohem Vertrauen entspricht, schaltet sie Leistungsart für Leistungsart um, Rückroll durchgehend behaltend. Die Würgefeigen-Fassade lässt Bürgerinnen einen kontinuierlichen Dienst über den Übergang hinweg sehen.

Geschäftsnutzen: Motivation, ROI und Gesamtbetriebskosten

Legacy-Modernisierung hat einen ungewöhnlichen Geschäftsfall, denn die größten Kosten sind oft die Kosten der Untätigkeit und das größte Risiko ist das Modernisierungsprojekt selbst. Die steigenden Kosten, nicht zu modernisieren, sind konkret: steigende Wartungs- und Lizenzkosten auf veraltenden Plattformen, eine zunehmend knappe und teure Spezialistenbelegschaft, Unfähigkeit, neue regulatorische oder Diensterfordernisse schnell zu erfüllen, und wachsende Exposition gegenüber einem katastrophalen Scheitern ohne jemanden übrig, der das System versteht. Dagegen sind die Kosten der Modernisierung hoch, und als Big Bang durchgeführt tragen sie eine wirklich hohe Scheiterwahrscheinlichkeit. Genau deshalb zählt der inkrementelle Ansatz für den ROI: er verwandelt eine einzelne große Wette in eine Reihe kleiner, von denen jede Wert zurückgibt und gestoppt werden kann.

Machen Sie den Fall gegenüber der Führung, indem Sie die Wahl umformulieren. Die Frage ist nicht “modernisieren oder nicht”. Sie ist “jetzt inkrementell modernisieren, oder eskalierende Betreuungskosten zahlen und einer erzwungenen, höherriskanten Modernisierung später unter Krise gegenüberstehen”. Quantifizieren Sie die Gesamtbetriebskosten des Status quo (Plattform- und Lizenzkosten, die Prämie für knappe Fähigkeiten, die risikogewichteten Kosten eines nicht erholbaren Ausfalls) und vergleichen Sie sie mit einem gestaffelten Programm, das Risiko und Kosten mit jedem Inkrement reduziert, während der Dienst laufend gehalten wird. Entscheidend, bestehen Sie darauf, dass jede vorgeschlagene Umschreibung strukturiert ist, früh und oft Wert zu liefern. Ein Programm, das drei Jahre nichts liefert und mit Totalverlust abgebrochen werden kann, ist keine Investition; es ist ein Glücksspiel. Das stärkste ROI-Argument für den Würgefeige-Ansatz ist Optionalität: Wert liefert kontinuierlich und die Organisation kann jederzeit den Kurs anpassen.

Anti-Muster und Fallstricke

Die Big-Bang-Umschreibung. Mehrjähriger, Alles-oder-nichts-Ersatz, der keinen Wert bis zum Ende liefert und häufig zu großen Kosten abgebrochen wird.
Umschreiben ohne Verständnis. Code ersetzen, dessen Geschäftsregeln nie dokumentiert wurden, still Randfälle fallen lassend, von denen echte Nutzerinnen und Gesetze abhängen.
Die Daten unterschätzen. Datenmigration als Nachgedanke behandeln, wenn es der schwierigste, riskanteste Teil des Projekts ist.
Dual-Running überspringen. Zum neuen System umschalten ohne parallelen Vergleich, Diskrepanzen erst entdeckend, nachdem sie echte Menschen betreffen.
Automatisierte Übersetzung als Lösung. COBOL maschinell zu einer modernen Sprache übersetzen und glauben, die Aufgabe ist getan, unverständlichen Code produzierend, der die alte Logik wörtlich reproduziert.
Nach Alter statt Risiko modernisieren. Aufwand auf alt-aber-stabile Systeme verwenden, während hochriskante, hochänderliche Systeme warten.
Das Wissen verlieren. Die letzten Betreuerinnen in Rente gehen lassen, ohne die Geschäftsregeln zu erfassen und Charakterisierungstests hinzuzufügen.
Kein Rückroll. Umschalten ohne Weg zurück, wenn sich das neue System unter echter Last und echten Daten schlecht verhält.

Reifegradmodell

Stufe 1: Beginnen. Legacy-Systeme werden gefürchtet und eingefroren; Änderung wird vermieden. Kein Inventar oder keine Risikobewertung existiert. Modernisierung, wenn überhaupt versucht, ist eine Ad-hoc-Alles-oder-nichts-Umschreibung, von Frustration getrieben. Wissen lebt in ein paar in Rente gehenden Köpfen ohne irgendetwas aufgeschrieben.
Stufe 2: Entwickeln. Manche Teams haben ein Inventar und ein grobes Gespür für Risiko, und ein paar Legacy-Systeme sind mit APIs für Zugriff umwickelt. Inkrementelle Muster sind bekannt, aber ungleichmäßig angewendet, und Denken driftet noch zu Big-Bang-Umschreibungen. Datenmigration wird versucht, aber unterschätzt, und die Praxis variiert stark von Team zu Team.
Stufe 3: Standardisieren. Systeme sind nach Risiko und Wert gegen eine dokumentierte, organisationsweite Methode priorisiert. Inkrementelle Muster (Würgefeige, Zweig-durch-Abstraktion) sind der durchgesetzte Standard, und jede Modernisierung folgt einem Standard-Playbook. Datenmigration ist ein geplanter, abgestimmter Aufwand mit Dual-Running vor dem Umschalten, und Wissenserfassung und Charakterisierungstests sind verlangte Praxis statt optional.
Stufe 4: Steuern. Modernisierung wird mit Daten gemessen und gesteuert. Der Bestand trägt Baselines: Betreuerinnen-Personalzahl und Rentenhorizont pro System, Charakterisierungstest-Abdeckung, Migrationsabstimmungs-Bestehensraten, Dual-Running-Diskrepanzzahlen, und gelieferten Wert pro Inkrement, alle gegen Ziele verfolgt. Betreuen-oder-Ersetzen-Entscheidungen und Umschalten-Go-oder-No-go-Rufe werden auf diesem Beleg getroffen, und ein System, das über seine Wissensrisiko-Schwelle abdriftet, löst Aktion aus statt auf eine Krise zu warten.
Stufe 5: Orchestrieren. Modernisierung ist kontinuierlich, mit Geschäfts- und Risikoplanung integriert, und adaptiv. Das Portfolio wird gegen Risikotrajektorie (besonders Wissensrisiko) neu ausbalanciert, während es sich verschiebt, inkrementeller Ersatz ist Routine und dramaarm, jedes Inkrement liefert Wert und ist umkehrbar, und die Organisation steuert das Tempo absichtlich. Lektionen aus jeder Migration speisen zurück in das geteilte Playbook, sodass sich der ganze Bestand über Zeit verbessert.

Diskussionsideen

Für Ihr kritischstes Legacy-System, wie viele Menschen können es noch pflegen, und wie nah sind sie am Gehen?
Wo werden Sie von einer Big-Bang-Umschreibung versucht, und welchen Wert könnte ein inkrementeller Ansatz stattdessen in den ersten drei Monaten liefern?
Wie gut sind die Geschäftsregeln in Ihren ältesten Systemen dokumentiert, und was geschieht mit ihnen, wenn der Code ersetzt wird?
Haben Sie die Daten profiliert, die Sie migrieren müssten, und wissen Sie, wie schmutzig und verwoben sie wirklich sind?
Welche alt-aber-stabilen Systeme verwenden Sie Modernisierungsenergie auf, die Sie sicher in Ruhe lassen könnten?
Könnten Sie Ihr neues System parallel zum alten laufen lassen und beweisen, dass sie übereinstimmen, bevor Sie umschalten?

Wichtigste Erkenntnisse

Legacy bedeutet wertvoll und grundlegend; respektieren und verstehen Sie ein System, bevor Sie es ändern.
Modernisieren Sie inkrementell mit der Würgefeige und Zweig-durch-Abstraktion, kontinuierlich Wert liefernd und jede Änderung klein und umkehrbar haltend.
Behandeln Sie die Big-Bang-Umschreibung als Standard-Scheitermodus; reservieren Sie sie für wirklich untragbare Plattformen und zerlegen Sie sie selbst dann.
Priorisieren Sie nach Risiko und Wert (besonders Wissensrisiko), nicht nach Alter; manche alten Systeme werden am besten betreut, nicht ersetzt.
Datenmigration und Dual-Running sind das Herz des Aufwands; profilieren, abstimmen, parallel laufen lassen, und Rückroll behalten.
Der stärkste Geschäftsfall ist Optionalität: inkrementelle Modernisierung verwandelt eine große, riskante Wette in viele kleine, wertzurückgebende.

Referenzen und weiterführende Literatur

Michael Feathers, Working Effectively with Legacy Code
Martin Fowler, “StranglerFigApplication” und “BranchByAbstraction”
Sam Newman, Monolith to Microservices
Nicholas Carr / Branchenstudien zu Großrechner- und COBOL-Abhängigkeit (Kontext zur Größe von Legacy-Beständen)
Robert Annett, Working with Legacy Systems
Eric Evans, Domain-Driven Design (Anti-Korruptions-Schicht)
Gregor Hohpe, Enterprise Integration Patterns und The Software Architect Elevator
Standish Group CHAOS Report (Beleg zu Großprojekt- und Umschreibungs-Scheiterraten)