Neuaufbau, Refactoring oder Wrapper: wie wir entscheiden, was mit Legacy-Software passiert

Der teuerste Satz in der Softwareentwicklung ist ein kurzer: „Lass es uns einfach neu schreiben."

Wir hören ihn ein paar Mal pro Jahr, meist von einem Team, das sich seit achtzehn Monaten über ein System geärgert hat, das im Großen und Ganzen noch funktioniert. Ein guter Teil unserer Arbeit bei SolutionPlus besteht darin, genau solche Systeme zu übernehmen: produktiv, in die Jahre gekommen, umsatzkritisch — und verhasst. Wir sind eine internationale Engineering-Organisation mit einem Senior-Team in Pakistan, wir liefern auf Englisch und Deutsch, und Software-Modernisierung gehört zu dem, was Kunden uns am häufigsten übergeben. Wir haben also eine Meinung zum Rewrite-Satz. Die wichtigste: Komplette Neuentwicklungen sind meist Ego, nicht Engineering. Joel Spolsky hat das kanonische Plädoyer gegen den großen Rewrite schon im Jahr 2000 geschrieben, und sechsundzwanzig Jahre, in denen Teams ihn ignoriert haben, haben den Essay nur treffender gemacht.

Manchmal ist ein Neuaufbau richtig. Er ist deutlich seltener richtig, als er vorgeschlagen wird.

Die drei Wege (und der vierte, über den niemand spricht: strategische Vernachlässigung)

Jedes Modernisierungsgespräch ist eine Wahl zwischen drei Optionen — plus einer, die nie auf dem Whiteboard landet.

Neuaufbau heißt: Die Implementierung wird weggeworfen und neu geschrieben, meist auf einem neuen Stack, während das Altsystem bis zur Umschaltung weiterläuft. Das Ergebnis ist der sauberste Endzustand — und die längste Phase, in der Sie für zwei Systeme zahlen, aber nur von einem profitieren. Wenn dieser Weg wirklich richtig ist, ist das System klein, gut verstanden und an den Rändern schmal: die Art System, die ein Team aus der Web-Entwicklung in einem Quartal neu implementieren kann, ohne Archäologie zu betreiben.

Refactoring heißt: Das System bleibt stehen und wird von innen verbessert. Module werden hinter getestete Schnittstellen ausgelagert, das Framework steigt Version für Version auf statt in einem heroischen Sprung. Die meisten langlebigen Systeme sind das, was Foote und Yoder schon 1997 als Big Ball of Mud beschrieben haben; Refactoring akzeptiert das und verbessert die Struktur, die Sie tatsächlich haben. Es fühlt sich langsamer an und liefert schneller — und es unterbricht das Tagesgeschäft nie.

Wrapper heißt: Der alte Kern bleibt unangetastet, und neuer Code wird darumgelegt — eine API-Fassade, ein modernes Frontend, eine Integrationsschicht, die zwischen der Legacy-Engine und allem Neuen übersetzt, das Sie bauen. Sie bekommen eine moderne Oberfläche auf einem alten Motor.

Der vierte Weg ist strategische Vernachlässigung: die bewusste Entscheidung, das System unangetastet zu lassen und das Geld anderswo auszugeben. Niemand schlägt das in Meetings vor, weil es nach Aufgabe klingt. Bei einem stabilen System, das sich zweimal im Jahr ändert und einfach funktioniert, ist es häufig die richtige Antwort — und ein ehrlicher Modernisierungspartner sollte diese Option prüfen, bevor er Ihnen irgendetwas verkauft.

Die Fragen, die die Entscheidung treffen

Wenn wir eine Discovery durchführen, fangen wir nicht mit dem Code an. Wir fangen mit vier Fragen an. Das Code-Review kommt später — diese Antworten geben ihm den Rahmen.

Wie oft ändert sich das System?

Das ist das stärkste Signal. Wenn das Unternehmen jede Woche Änderungen anfragt und jede drei Wochen bis zum Release braucht, zahlt das Unternehmen eine aktive Steuer an das System — und die Steuer wächst mit Zinseszins. Das drückt Sie Richtung Refactoring oder Neuaufbau. Ändert sich das System zweimal im Jahr und jede Änderung ist klein, ist die Steuer real, aber winzig: Wrapper drum oder in Ruhe lassen. Wir haben einem Kunden einmal davon abgeraten, ein Reporting-Tool neu zu bauen, das im Jahr davor genau vier Änderungswünsche gesehen hatte. Der Kunde behielt das Tool und steckte das Budget in das Produkt, das tatsächlich Geld brachte. Das war ein gutes Projekt, auch wenn die Rechnung kleiner ausfiel.

Wie groß ist die Integrationsfläche?

Zählen Sie alles, was mit dem System spricht: das ERP, das CRM, den Zahlungsanbieter, die Versand-API, die Tabelle, die ein Buchhalter jeden Freitag exportiert und in drei andere Tools einspeist. Jede Integration ist ein Vertrag. Ein Neuaufbau verhandelt alle gleichzeitig neu — und die, die niemand dokumentiert hat, sind die, die bei der Umschaltung brechen. Eine breite Integrationsfläche spricht gegen den Neuaufbau und für einen Wrapper oder eine inkrementelle Migration. Eine schmale — zwei, drei dokumentierte APIs — lässt alle Optionen offen.

Wer versteht das System noch?

Legacy-Systeme kodieren Geschäftsregeln, die sonst nirgendwo existieren. Michael Feathers eröffnet Working Effectively with Legacy Code mit der Definition, Legacy-Code sei Code ohne Tests — und das tiefere Problem ist, dass der Code oft die einzige Dokumentation ist, die das Unternehmen hat. Wenn die Person, die die Abrechnungslogik verstanden hat, 2022 gegangen ist, bedeutet ein Rewrite, diese Regeln per Trial and Error wiederzuentdecken. Einige werden Sie über verärgerte Kunden wiederentdecken. Das ist die versteckte Position in jeder Neuaufbau-Kalkulation — und der Grund, warum Refactoring die sicherere Standardeinstellung ist: Die Regeln laufen weiter, während Sie die Tests schreiben, die sie endlich festhalten.

Wie viel Ausfallzeit kann das Unternehmen vertragen?

„Wir schalten einfach an einem Wochenende um" ist eine Warnflagge, die wir in Vertriebsgesprächen hören. Wenn die ehrliche Antwort zur Ausfallzeit „keine" lautet, ist die Big-Bang-Umschaltung vom Tisch — das streicht die meisten Neuaufbau-Pläne in ihrer üblichen Form und drückt Sie Richtung inkrementeller Migration. Kann das Unternehmen ein Wartungsfenster verkraften, bleiben mehr Optionen offen. Lassen Sie sich die Antwort schriftlich geben, bevor Sie irgendetwas kalkulieren.

Was jeder Weg an Zeit und Risiko kostet

Die Systeme, die wir übernehmen, sind meist ein Jahrzehnt oder älter und ein, zwei Framework-Versionen im Rückstand — die folgenden Kostenprofile stammen aus genau diesen Projekten.

Ein Wrapper wird in Wochen gemessen. In unseren Projekten hat eine Fassade plus neues Frontend auf einem stabilen Legacy-Kern vier bis zehn Wochen gedauert. Das Risiko: Sie erben alles darunter. Der Wrapper macht das System angenehm zu benutzen und ändert nichts daran, dass es teuer zu ändern ist. Betrachten Sie ihn als Zeitkauf, nicht als Problemlösung.

Refactoring wird in Monaten gemessen. In unseren Modernisierungsprojekten lief eine mittelgroße Geschäftsanwendung drei bis neun Monate — parallel zur normalen Feature-Arbeit, nicht an ihrer Stelle. Das Risiko ist Disziplin. Refactoring stirbt an tausend verschobenen Aufräumarbeiten; es braucht ein Team, das das Aufräumen als die Arbeit behandelt, nicht als Hobby nach der Arbeit.

Neuaufbau wird in Quartalen gemessen: sechs bis achtzehn Monate für alles mit echter Geschäftslogik, gemessen an den Neuaufbauten, zu deren Angebot oder Rettung wir geholt wurden. Die erste Schätzung hält selten, und der Grund sind die letzten zehn Prozent. Das Exportformat, von dem ein einzelner Kunde abhängt. Die Preisregel von 2019, an die sich niemand erinnert, nach der aber alle abrechnen. Die ersten neunzig Prozent eines Rewrites sind der leichte Teil — deshalb sehen Rewrite-Demos im zweiten Monat immer großartig aus.

Ein Kunde kam zu uns mit einer Abrechnungsplattform, gut zehn Jahre alt, zwei Framework-Versionen im Rückstand, Deployments von einem halben Tag und einem Release-Zyklus, der sich auf monatlich gedehnt hatte. Ein Neuaufbau lag auf dem Tisch und hätte den größten Teil eines Jahres gefressen. Wir haben stattdessen refaktoriert. Zuerst wurde die Deployment-Pipeline automatisiert, damit Releases sicher sind, dann kam die Fakturierungs-Engine hinter ein getestetes Interface, und das Framework stieg in Schritten auf. Die Release-Vorlaufzeit fiel von Wochen auf Tage, und das Unternehmen hat nie aufgehört zu verkaufen. Unsere Fallstudien beschreiben ähnliche Projekte im Detail.

Unsere Projekte fallen meist in ein paar typische Formen. Ein Stabilisierungs-Sprint von zwei bis vier Wochen stoppt die Blutung: Tests um die riskantesten Pfade und eine Deploy-Pipeline, die nicht mehr vom Laptop einer bestimmten Person abhängt. Ein inkrementeller Modernisierungs-Retainer gibt Ihnen feste monatliche Kapazität, die parallel zu Ihrer Roadmap herauslöst und refaktoriert. Für Teams, die den gesamten Betrieb abgeben wollen, arbeiten wir im Build-Operate-Transfer-Modell: Wir modernisieren das System, betreiben es und übergeben am Ende ein Team, das es besitzt. Und manchmal endet ein Projekt damit, dass wir Ihnen raten, nichts zu tun — damit wären wir wieder bei der strategischen Vernachlässigung.

Das Migrationsmuster, zu dem wir am häufigsten greifen

Wenn wir migrieren, greifen wir am häufigsten zum Strangler Pattern (Strangler Fig), benannt von Martin Fowler nach der Würgefeige, die um einen Wirtsbaum wächst, bis der Baum verschwunden ist. In der Praxis läuft es so: Sie setzen eine Routing-Schicht vor das Altsystem. Neue Funktionen entstehen im neuen System, hinter dem Router. Eine nach der anderen lösen Sie bestehende Funktionen heraus, bauen sie neu und schalten die Route um. Wenn der Traffic auf ein altes Modul auf null fällt, löschen Sie es. Es gibt kein Umschalt-Wochenende, weil es keine Umschaltung gibt.

Ein zweiter Kunde betrieb ein Auftragsmanagementsystem direkt neben seinem ERP, und das Unternehmen durfte niemals aufhören, Bestellungen anzunehmen. Wir haben es zuerst umhüllt, damit neue Arbeit gegen eine saubere API laufen konnte, und es dann über gut ein Jahr stranguliert: zuerst die Kundenverwaltung, dann die Preise, zuletzt der Bestellworkflow, weil er der riskanteste war. Das Altsystem schrumpfte, statt zu explodieren. Die Gesamtausfallzeit über die gesamte Migration war null — genau das Ergebnis, für das dieses Muster existiert.

Der Nachteil, offen ausgesprochen: Den größten Teil dieses Jahres zahlte der Kunde für den Betrieb zweier Systeme plus Routing-Schicht — und der Router selbst ist Code, den Sie pflegen und irgendwann löschen müssen. Bei einem kleinen System kann die Fassade teurer sein als ein schlichter Rewrite. Das Strangler Pattern rechtfertigt seinen Overhead, wenn Ausfallzeit inakzeptabel ist und das System zu groß und zu fest verdrahtet, um es in einem Zug neu zu schreiben. Wenn diese Bedingungen nicht zutreffen, sagen wir das — und bieten den einfacheren Job an.

Die Entscheidung ist vor allem eine Geschäftsentscheidung

Hier ist die Schwelle, die wir anlegen. Zählen Sie, was das Unternehmen im letzten Jahr vom System verlangt hat — einschließlich der Wünsche, die es aufgegeben hat, weil das System sie nicht aufnehmen konnte. Ist diese Zahl niedrig, wie beim Reporting-Tool mit vier Änderungswünschen im Jahr, lassen Sie das System in Ruhe und investieren das Budget dort, wo es Ertrag bringt. Wenn die abgelehnten Änderungen das Produkt zurückhalten, zahlen Sie Steuer an das System, und die Antworten oben zeigen, welcher Weg diese Steuer abschafft. Wenn Sie ein zweites Augenpaar auf diese Zählung wollen, sprechen Sie mit uns. Die Antwort könnte Neuaufbau lauten. Meist tut sie es nicht.