Neu bauen oder retten? Wann sich der Rewrite einer Software lohnt

Der Satz, der nach Befreiung klingt

Jede in die Jahre gekommene Software erreicht irgendwann den Punkt, an dem jemand entnervt sagt: Am besten schreiben wir das Ganze neu. Der Satz fühlt sich gut an. Weg mit dem alten Ballast, weg mit dem Code, den niemand mehr versteht, endlich sauber von vorne. Nach Jahren des Flickens klingt der Neubau wie eine Befreiung.

Genau darum ist er so gefährlich. Ein kompletter Neubau, im Fachjargon Rewrite, ist eine der teuersten und riskantesten Entscheidungen, die man in einem Softwareprodukt treffen kann. Er geht überraschend oft schief, und zwar nicht wegen fehlenden Könnens, sondern weil die Rechnung von Anfang an nicht aufgeht. Bevor du sie triffst, lohnt es sich zu verstehen, was du da wirklich abwägst.

Warum der Reiz zum Neubau trügt

Der Wunsch nach dem Neubau speist sich aus einem realen Schmerz. Die alte Software ist unübersichtlich, jede Änderung dauert, jeder Eingriff bricht an anderer Stelle etwas. Das nennt man technische Schulden, und sie sind real. Der Trugschluss liegt woanders: in der Annahme, ein Neubau wische diese Schulden einfach weg.

Zwei Dinge werden dabei fast immer übersehen. Erstens steckt in der alten Software mehr Wissen, als man glaubt. Jede seltsame Sonderregel, jeder komische Spezialfall ist meist die Narbe eines echten Problems, das irgendwann jemand gelöst hat. Baust du neu, baust du all diese unsichtbaren Lösungen unwissentlich wieder ab und stolperst über dieselben Probleme von vorne.

Zweitens läuft die alte Software weiter, während du die neue baust. Deine Kunden erwarten neue Funktionen und Fehlerbehebungen. Du musst also beide Welten gleichzeitig pflegen, und der Neubau muss erst einmal all das können, was das Alte schon konnte, bevor er irgendeinen Mehrwert bringt. Genau in dieser langen, mehrwertfreien Zwischenzeit sterben die meisten Rewrites.

Wann ein Neubau wirklich der richtige Weg ist

Es gibt Fälle, in denen der Neubau nicht Flucht ist, sondern die richtige Entscheidung. Sie sind seltener, als man denkt, aber sie existieren.

Ein echter Grund ist eine technische Grundlage, die nicht mehr trägt und sich nicht schrittweise ersetzen lässt, etwa eine Basistechnologie, für die es keine Sicherheitsupdates mehr gibt und keine Entwickler mehr am Markt. Ein zweiter ist ein Produkt, dessen Zweck sich so grundlegend gewandelt hat, dass die alte Struktur dem Neuen im Weg steht, nicht in Details, sondern im Kern. Ein dritter ist eine Software, die so klein und klar abgegrenzt ist, dass ein Neubau überschaubar bleibt und in Wochen statt in Jahren zu haben ist.

Die gemeinsame Bedingung all dieser Fälle: Der Neubau ist beherrschbar und hat ein absehbares Ende. Sobald der Neubau selbst zum Grossprojekt mit ungewissem Ausgang wird, kippt die Rechnung. Das ist dieselbe nüchterne Sicht, die auch ein festgefahrenes Softwareprojekt rettet: erst den wahren Zustand anschauen, dann entscheiden.

Die meist bessere Alternative: sanieren im Betrieb

In den allermeisten Fällen ist der richtige Weg nicht Abriss, sondern Umbau bei laufendem Betrieb. Statt alles auf einmal zu ersetzen, löst du Teil für Teil ab. Du suchst dir den schlimmsten, schmerzhaftesten Bereich, baust ihn sauber neu und hängst ihn an die bestehende Software an. Dann den nächsten. Und den nächsten.

Der Vorteil liegt auf der Hand: Jeder Schritt bringt sofort einen spürbaren Nutzen, das Produkt bleibt die ganze Zeit lauffähig, und du kannst jederzeit anhalten oder die Richtung ändern. Du bindest kein riesiges Budget in ein Projekt, das erst nach zwei Jahren zum ersten Mal etwas liefert. Stattdessen wird die Software Monat für Monat besser, während sie weiter Geld verdient. Das ist mühsamer als der grosse Wurf, weil es Disziplin verlangt und keinen sauberen Schnitt erlaubt. Aber es ist der Weg, der weit öfter gut ausgeht.

Die nüchterne Kostenrechnung

Beim Vergleich der beiden Wege wird meist nur eine Seite betrachtet: die Baukosten. Die eigentliche Rechnung ist grösser. Ein Neubau kostet nicht nur die Entwicklung, sondern auch die Zeit, in der du parallel zwei Systeme pflegst, das Risiko, dass er länger dauert als geplant, und die verpassten Verbesserungen am bestehenden Produkt, weil alle Kraft in den Neubau fliesst.

Die schrittweise Sanierung verteilt die Kosten über die Zeit und macht sie steuerbar. Du zahlst für sichtbaren Fortschritt statt für ein Versprechen. Diese Logik ist dieselbe wie bei der Frage, warum Software nach dem Launch teuer wird: Die Summe entsteht nicht im grossen Wurf, sondern im Laufenden, und genau dort lässt sie sich am besten kontrollieren.

Wenn dennoch neu gebaut wird, ist ein Punkt entscheidend: Die Daten aus dem alten System müssen sauber mit. Wie heikel das ist, zeigt der Artikel zum Migrieren von Daten aus Altsystemen. Eine unterschätzte Migration hat schon manchen sauber gebauten Neubau zum Stillstand gebracht.

Die richtige Frage stellen

Neu bauen oder retten ist selten eine reine Technikfrage, auch wenn sie so daherkommt. Sie ist eine Frage von Risiko, Budget und Nerven. Der Neubau lockt, weil er sich sauber anfühlt, aber sauber im Kopf heisst nicht sicher in der Umsetzung.

Die nüchterne Reihenfolge lautet: Zuerst den echten Zustand der Software anschauen, statt aus Frust zu entscheiden. Dann prüfen, ob sich das eigentliche Problem nicht schrittweise lösen lässt, ohne alles aufs Spiel zu setzen. Und nur dann komplett neu bauen, wenn der Neubau überschaubar ist und ein klares Ende hat. Genau diese Einschätzung machen wir im Rahmen von Individualsoftware und Produkt & Betrieb. Wenn bei euch gerade der Satz mit dem Neuschreiben fällt, sprecht mit uns, bevor die Entscheidung fällt. Eine nüchterne zweite Meinung ist günstiger als ein abgebrochener Rewrite.