Legacy-Software modernisieren ohne Big-Bang-Rewrite

Fast jedes etablierte Unternehmen hat so eine: eine Software, die alle still verabscheuen. Sie ist langsam, sie ist hässlich, die halbe Mannschaft kennt einen Workaround für den Fehler, den nie jemand behoben hat, und die eine Person, die sie verstanden hat, ist 2019 gegangen. Der Reflex ist immer derselbe — alles niederreißen und neu bauen. Und genau dieser Reflex ist häufig der Grund, warum gute Unternehmen ein Jahr und ein kleines Vermögen für nichts verlieren.

Ich habe oft genug gesehen, wie der große Rewrite schiefgeht, um einen Reflex dagegen entwickelt zu haben. Ein Gründer zeigt mir sein ächzendes Auftragssystem oder sein uraltes Planungswerkzeug, seufzt und sagt irgendeine Variante von „wir müssen einfach das Ganze ersetzen.“ Und vielleicht werden Sie das eines Tages tun. Aber der komplette Rewrite — das alte System herausreißen, parallel ein glänzendes neues bauen, einen Schalter umlegen — gehört zu den riskantesten Manövern in der gesamten Software. Er ist teuer, er dauert weit länger als versprochen, und die ganze Zeit über fahren Sie blind und hoffen, dass das Neue jeden kuriosen Sonderfall abdeckt, den das Alte fünfzehn Jahre lang stillschweigend erledigt hat.

Die gute Nachricht: Der Big-Bang-Rewrite ist fast nie die einzige Option und selten die beste. Es gibt einen ruhigeren Weg zur Modernisierung — schrittweise, umkehrbar und schonend für das Unternehmen, das nebenbei weiter Geld verdienen muss. Dieser Leitfaden zeigt diesen Weg: wie Sie erkennen, was wirklich behoben werden muss, wie Sie die schmerzhaften Teile ersetzen, ohne das ganze System lahmzulegen, und wie Sie wissen, wann ein vollständiger Rewrite tatsächlich die richtige Entscheidung ist.

Warum der Big-Bang-Rewrite so verlockend — und so gefährlich ist

Der komplette Rewrite ist verführerisch, weil er einen sauberen Neuanfang verspricht. Kein Legacy-Chaos mehr, keine Kompromisse, eine frische Codebasis, von Anfang an richtig gebaut mit modernen Werkzeugen. Auf dem Whiteboard sieht es einleuchtend aus. In Wirklichkeit verpflichten Sie sich, Jahre an angesammelter Geschäftslogik nachzubauen — vieles davon undokumentiert, manches nur noch in den Köpfen von Menschen, die längst weg sind — während die Uhr läuft und die Rechnungen eintreffen.

Die tiefere Falle ist das Parallelwelt-Problem. Für die Monate oder Jahre, die der Ersatz braucht, haben Sie zwei Systeme: das alte, das weiterhin den Betrieb tragen muss, und das neue, das noch nicht fertig ist. Jede Änderung, die das Unternehmen braucht, muss doppelt gemacht werden — sonst hinkt das neue System der Realität hinterher, bevor es überhaupt startet. Teams brennen aus, weil sie beide am Leben halten. Und weil niemand umschalten darf, bis das neue System alles kann, gibt es keinen frühen Erfolg, kein Feedback, keinen Beweis, dass es funktioniert — nur ein langes, bangendes Warten auf einen einzigen, riesigen Alles-oder-nichts-Starttag.

Es gibt hier eine bekannte Weisheit aus der Branche, und sie ist verdient: Das zweite System, der große Rewrite, neigt dazu, dreimal so lange zu dauern wie geschätzt und mit weniger Funktionen anzukommen als das, was es ersetzt. Die Schätzung ist nicht falsch, weil Menschen nachlässig sind. Sie ist falsch, weil zu Beginn niemand all die kleinen Dinge sehen kann, die das alte System klaglos richtig macht.

Was 'Legacy' wirklich bedeutet (es geht nicht ums Alter)

Wir werfen mit dem Wort Legacy um uns, als hieße es einfach „alt“. Das tut es nicht. Jede Menge Software, die seit einem Jahrzehnt läuft, ist völlig in Ordnung — unspektakulär, stabil, bezahlt, sie tut ihren Job. Alter allein ist kein Grund, irgendetwas anzufassen. Der teuerste Fehler in diesem ganzen Feld ist, etwas zu modernisieren, das still funktioniert hat, nur weil es alt aussah.

Software verdient das Etikett Legacy, wenn sie Ihnen aktiv im Weg steht. Wenn Sie sie nicht gefahrlos ändern können, weil niemand sie ganz versteht. Wenn sie sich nicht mit den Werkzeugen verbinden lässt, von denen Sie heute abhängen. Wenn eine einzige Person die Einzige ist, die sie am Leben hält. Wenn sie so langsam oder fragil ist, dass Ihr Team eine ganze Folklore aus Workarounds darum herum aufgebaut hat. Das ist die wahre Definition — nicht das Jahr, in dem sie geschrieben wurde, sondern die Kosten, die sie Ihnen heute aufbürdet, und das Risiko, das sie in den nächsten Tag trägt.

Diagnostizieren, bevor Sie irgendetwas anfassen

Bevor eine einzige Zeile umgeschrieben wird, brauchen Sie eine ehrliche Karte davon, wo der Schmerz tatsächlich sitzt. Meistens ist das System, das alle hassen, zu 80 % in Ordnung. Die Probleme ballen sich an wenigen konkreten Stellen — ein langsamer Bildschirm, eine kaputte Integration, ein Ablauf, der doppelte Dateneingabe erzwingt — und diese wenigen Stellen erzeugen nahezu alle Beschwerden. Finden Sie sie, und Sie haben Ihr ganzes Projekt gefunden.

Der Weg, sie zu finden, ist nicht zuerst ein technisches Audit — es ist ein Gespräch. Setzen Sie sich zu den Menschen, die das Ding jeden Tag benutzen, und fragen Sie, wo es wehtut. Wo warten sie? Was tippen sie erneut? Was meiden sie, weil es schmerzhaft ist? Wo führen sie eine private Tabelle, um das offizielle System zu umgehen? Diese Workarounds sind Gold: Jeder ist ein präzises Röntgenbild eines Problems, das sich zu beheben lohnt.

• Die Bildschirme und Schritte, über die sich Menschen am meisten beschweren — nicht in der Theorie, sondern in ihrer tatsächlichen täglichen Arbeit.
• Jede Stelle, an der Daten doppelt eingegeben werden, weil zwei Systeme nicht miteinander reden.
• Die Integrationen, die kaputtgingen oder nie existierten und manuelles Kopieren zwischen Werkzeugen erzwingen.
• Alles, was nur eine Person bedienen oder reparieren kann — Ihre Single Points of Failure.
• Die Teile, die wirklich in Ordnung sind, damit Sie sie schützen und in Ruhe lassen können.
• Was das Unternehmen nächstes Jahr brauchen wird und in das das aktuelle System schlicht nicht hineinwachsen kann.

Wenn Sie das ehrlich tun, schrumpft das Projekt meist. Der Eigentümer, der mit „alles ersetzen“ hereinkam, geht mit der Erkenntnis, dass er drei Dinge beheben muss. Das ist keine Enttäuschung — es ist eine Erleichterung. Drei behebbare Dinge sind ein Projekt, das Sie dieses Quartal abschließen können. Ein kompletter Ersatz ist ein Jahr, das Sie vielleicht nicht überstehen.

Der Strangler-Ansatz: ersetzen Sie es Stück für Stück

Es gibt ein Muster, um das sicher zu tun, und es trägt einen etwas düsteren, aber einprägsamen Namen: den Strangler-Ansatz, nach der Würgefeige — einer Ranke, die um einen Baum wächst und allmählich seine Struktur übernimmt, bis schließlich der neue Wuchs für sich allein steht und der alte Stamm verschwunden ist. Auf Software übertragen ist die Idee wunderbar praktisch: Sie ersetzen das alte System nicht in einem heroischen Schlag. Sie lassen das neue darum herumwachsen, Stück für Stück, bis vom Alten nichts mehr übrig ist, das noch jemand braucht.

In der Praxis läuft es so. Sie wählen ein schmerzhaftes Stück — sagen wir das Rechnungsmodul, das alle hassen. Sie bauen einen modernen Ersatz für genau dieses Stück. Sie leiten die Rechnungsstellung zum neuen Modul, während alles andere unangetastet auf dem alten System weiterläuft. Sie beobachten es eine Weile. Wenn es solide ist, wird dieser Teil des alten Systems still, und Sie gehen zum nächsten Stück. Das alte System schrumpft allmählich, wie eine Kerze, statt auf einen Schlag niedergerissen zu werden.

Was das so viel sicherer macht als einen Rewrite, ist, dass jeder Schritt klein, live und umkehrbar ist. Sie fahren nie blind. Jedes neue Stück geht schnell in den echten Einsatz, sodass Sie rasch herausfinden, ob es tatsächlich funktioniert. Geht etwas schief, haben Sie nur ein Modul riskiert, nicht das ganze Unternehmen — und Sie können meist auf den alten Weg zurückfallen, während Sie es beheben. Sie erzielen unterwegs Erfolge statt eines einzigen schrecklichen Starts am Ende. Und das Unternehmen läuft die ganze Zeit ganz normal weiter.

Wie der Rhythmus tatsächlich aussieht

1. 1
   Wählen Sie das schmerzhafteste, in sich geschlossenste Stück

   Sie wollen hohen Schmerz und saubere Kanten — ein Modul, das stark wehtut und nicht seine Finger überall mit drin hat. Das ist Ihr erstes Ziel.
2. 2
   Setzen Sie eine dünne Schicht vor das alte System

   Eine kleine Routing-Schicht entscheidet, welche Anfragen ans alte System gehen und welche ans neue Stück. Das ist die Naht, die alles andere möglich macht.
3. 3
   Bauen und starten Sie nur dieses eine Stück

   Ersetzen Sie ein Modul, bringen Sie es in echte Hände und leiten Sie nur diesen Ausschnitt der Arbeit dorthin. Wochen, nicht Jahre — und der Rest des Systems hat sich nie bewegt.
4. 4
   Stabilisieren, dann zum nächsten Stück gehen

   Sobald dem neuen Modul vertraut wird, geht der passende Teil des alten Systems in Ruhestand. Wiederholen Sie es mit dem nächsten schmerzhaften Stück und lernen Sie dabei.
5. 5
   Das alte System abschalten, wenn es leer ist

   Irgendwann tut das Altsystem nichts mehr, worauf sich jemand verlässt. Erst dann schalten Sie es ab — leise, ohne Drama, weil alles Wichtige längst umgezogen ist.

Beachten Sie, was hier anders ist als beim Rewrite: Es gibt keinen einzigen Starttag zu fürchten. Es gibt keine Parallelwelt zu pflegen. Das neue System ist ab Woche drei in Produktion, verdient seinen Unterhalt und lehrt Sie Dinge, statt in einem Labor auf einen Start zu warten, der immer wieder verrutscht.

Manchmal müssen Sie es gar nicht ersetzen

Bevor Sie überhaupt etwas ersetzen, lohnt die Frage, ob das alte System ersetzt werden muss oder nur aufhören muss, eine Insel zu sein. Erstaunlich viele „wir brauchen ein neues System“-Probleme sind in Wahrheit „unsere Systeme reden nicht miteinander“-Probleme. Die alte Software macht ihren Job gut — sie sitzt nur in einem Silo und zwingt die Leute, Daten von Hand hin und her zu tragen.

In diesen Fällen ist die billigste, schnellste Lösung kein neues System. Es ist eine Brücke. Sie ummanteln die alte Software mit einer Verbindung — einer Integration, die sie automatisch Daten mit Ihren anderen Werkzeugen austauschen lässt — und einer modernen Schicht obenauf für die Teile, die Menschen tatsächlich anfassen. Der betagte Motor brummt darunter weiter; das Team bekommt eine saubere Oberfläche und ein Ende des Kopierens und Einfügens. Es ist nicht glamourös, aber oft der höchste Ertrag pro Euro im ganzen Vorhaben.

Wann ein vollständiger Rewrite wirklich richtig ist

Ich habe diesen ganzen Leitfaden damit verbracht, Ihnen den großen Rewrite auszureden, also sei es fair gesagt: Manchmal ist er wirklich die Antwort. Es gibt Fundamente, die so morsch sind, dass kein Flicken, Überbrücken oder schrittweises Ersetzen sie rettet, und so zu tun, als wäre es anders, verschiebt nur das Unvermeidliche, während Sie Geld dafür ausgeben, eine Leiche zu stützen.

Die ehrlichen Zeichen sind eindeutig. Die Technologie, auf der das System aufbaut, ist tot oder sterbend — kein Support, keine Sicherheitsupdates, niemand mehr da, der daran arbeiten kann. Das Geschäft hat sich so grundlegend verändert, dass das alte Modell die Realität gar nicht mehr abbildet. Oder das System ist so verheddert, dass selbst kleine Änderungen regelmäßig Dinge an unverbundenen Stellen kaputt machen — was meist bedeutet, dass es überhaupt keine sauberen Nähte für einen Strangler-Ansatz gibt. Wenn zwei oder drei davon zugleich zutreffen, ist die schrittweise Arbeit nicht mehr die sicherere Wahl.

Und hier ist der stille Lohn dafür, die schrittweise Arbeit zuerst zu tun, selbst wenn Sie am Ende doch neu bauen: Bis Sie dort ankommen, verstehen Sie das System weit besser als zu Beginn. Jedes Modul, das Sie ersetzt haben, hat Ihnen etwas beigebracht, das die ursprünglichen Autoren nie aufgeschrieben haben. Ein Rewrite, der auf diesem Wissen beruht, ist ein völlig anderes, weit sichereres Tier als einer, der auf Tag-eins-Optimismus gestartet wird.

Der Teil, den niemand erwähnt: es geht meist um Menschen

Hier ist etwas, das die technischen Leitfäden überspringen. Der schwerste Teil beim Modernisieren alter Software ist meist nicht der Code — es sind die Menschen, die sich jahrelang daran angepasst haben. Sie kennen ihre Macken. Sie haben Muskelgedächtnis für ihre schrägen Abkürzungen. Ein neues Modul, das objektiv besser ist, kann sich in den ersten zwei Wochen trotzdem schlechter anfühlen, einfach weil es ungewohnt ist. Wenn Sie das ignorieren, kann selbst eine perfekte technische Migration scheitern.

Der schrittweise Ansatz hilft auch hier, fast nebenbei. Weil die Veränderung in kleinen Stücken ankommt, nehmen die Menschen sie allmählich auf, statt an einem einzigen Montagmorgen alles neu lernen zu müssen. Holen Sie die täglichen Nutzer früh dazu. Lassen Sie sie den Ersatz mitgestalten, bevor er fertig ist. Das Team, das die neue Rechnungsmaske mitentworfen hat, wird sie verfechten; das Team, dem sie vor die Füße geworfen wurde, wird sie ablehnen, selbst wenn sie identisch ist. Modernisierung ist ein Change-Management-Projekt im Software-Kostüm.

Häufige Fragen