Der Neubau-Irrtum: Warum ein Software-Rewrite Tempo kostet

Irgendwann wird die zentrale Anwendung träge, unübersichtlich, technisch überladen. Das Entwicklungsteam schlägt vor, sie von Grund auf neu zu bauen — mit einem modernen Framework, sauber, ohne Altlasten. Die Leitung gibt ein mehrjähriges Projekt frei. Zwei Jahre später ist das Budget überzogen, wichtige Funktionen fehlen, und das alte System läuft immer noch, weil man es nicht abschalten kann. Dieses Muster wiederholt sich in erstaunlich vielen Häusern.

Das Muster

Der Neubau auf dem weißen Blatt ist eine verlockende Fata Morgana. Er unterstellt, dass sich technische Schulden einfach hinter sich lassen lassen, wenn man nur frisch anfängt. Was dabei übersehen wird: Alte Software ist nicht bloß alter Quellcode. Sie ist ein lebendes Verzeichnis von tausenden Sonderfällen, individuellen Geschäftsregeln und Fehlerkorrekturen, die über Jahre im echten Betrieb erkämpft wurden. Jede dieser Kleinigkeiten steht für eine Situation, in der einmal etwas schiefging und jemand es geradezog.

Wer bei null beginnt, wirft dieses gesammelte Betriebswissen weg. Der Großteil des Aufwands fließt dann gar nicht in neue Fähigkeiten, sondern nur darin, den Funktionsstand des alten Systems überhaupt wieder zu erreichen. Der Nutzer sieht nach langer Zeit und großer Investition im besten Fall dasselbe wie vorher — nur mit neuen, noch unentdeckten Fehlern. In der Zwischenzeit steht die Weiterentwicklung still, weil alle Kräfte im Neubau gebunden sind.

Aus unserer Praxis

Als kleines, effizienzgetriebenes Beratungshaus lehnen wir vollständige System-Neubauten bewusst ab. Wir arbeiten konsequent nach dem Strangler-Fig-Muster — dem Bild der Würgefeige, die einen Baum langsam umschließt und schließlich ersetzt. Das Kernsystem bleibt in Betrieb. Wir lösen einzelne, besonders schmerzhafte Arbeitsabläufe nacheinander heraus.

Konkret sieht das so aus:

1. Den größten Schmerzpunkt zuerst. Wir suchen den Teil, der am meisten Reibung verursacht — nicht den technisch interessantesten, sondern den, der den Alltag am spürbarsten ausbremst.
2. Eine Brücke bauen. Über diese eine Komponente legen wir einen modernen Baustein oder eine schlanke Web-Oberfläche, die sauber an das bestehende System andockt.
3. Den Nutzen belegen. Sobald der neue Baustein läuft, zeigt sich sofort, ob er trägt. Erst wenn das steht, gehen wir zum nächsten Stück über.

Dieses schrittweise Vorgehen hält das Risiko für die Organisation klein. Es gibt keinen großen Stichtag, an dem alles auf einmal umgestellt wird und alles auf einmal schiefgehen kann. Stattdessen liefert jeder Monat einen messbaren Fortschritt, und das Tagesgeschäft läuft ununterbrochen weiter. Das ist der entscheidende Punkt: Modernisierung darf das Tempo des Betriebs nicht anhalten, um es später vielleicht wiederzufinden.

Wann ein Neubau doch sinnvoll ist

Es gibt Ausnahmen, und wir benennen sie ehrlich. Wenn die zugrundeliegende Technik nicht mehr betrieben werden kann, wenn niemand mehr das nötige Wissen hat oder ein Sicherheitsrisiko nicht anders zu schließen ist, führt kein Weg an einem größeren Schnitt vorbei. Aber auch dann bauen wir nicht blind neu, sondern sichern zuerst das Erfahrungswissen aus dem alten System — die Sonderfälle, die Ausnahmen, die ungeschriebenen Regeln. Sie sind das eigentliche Kapital, nicht der Code.

Fazit

Ein langsames System ist ein echtes Problem, aber der komplette Neubau ist selten die Antwort. Er verspricht einen sauberen Anfang und liefert oft nur einen teuren Umweg zurück zum Ausgangspunkt. Wer stattdessen Stück für Stück modernisiert, behält das Erfahrungswissen, das Tempo und die Kontrolle. Wenn ihr überlegt, ob eure Anwendung einen Neustart braucht oder besser einen schrittweisen Umbau: Wir schauen uns gern gemeinsam an, wo der erste sinnvolle Schnitt liegt.