Relaunch vs. Legacy Code: Wann ist ein Neuanfang sinnvoll?
Viele Projekte wachsen über Jahre, werden erweitert, gefixt und mit neuen Features versehen. Bis man irgendwann merkt, dass der Aufwand immer größer wird. Alte Frameworks, schwer wartbarer Code und steigende Entwicklungskosten werfen die Frage auf, ob ein kompletter Neustart nicht günstiger und zukunftssicherer wäre.
Die Antwort darauf ist selten schwarz oder weiß. Manchmal ist der alte Code nur ein bisschen "in die Jahre gekommen", manchmal hat er so viel Charakter wie eine seit Tagen geöffnete Flasche Prosecco. Doch wann lohnt sich ein Refactoring und wann ist es besser, gleich alles neuzuschreiben? Darum geht es in diesem Artikel.
Relaunch vs. Weiterentwicklung: Erfahrungsberichte und Kriterien
Die Entscheidung zwischen einem Relaunch und der Weiterentwicklung einer bestehenden Codebasis ist oft komplexer, als sie auf den ersten Blick wirkt. Während ein kompletter Neustart nach einem sauberem Schnitt klingt, bedeutet er auch hohe Anfangsinvestitionen, Risiken und das Abschreiben wertvoller Erfahrungen. Auf der anderen Seite kann das Festhalten an alter Software und Legacy Code teuer werden, wenn technische Schulden, steigende Wartungskosten und fehlende Flexibilität Innovationen blockieren.
Erfahrungsberichte von Entwicklerinnen, Agenturen und Unternehmen zeigen, dass die richtige Wahl oft von einem Mix aus wirtschaftlichen, technologischen und organisatorischen Kriterien abhängt. Im Folgenden versuche ich eine Übersicht dieser Faktoren, ergänzt um konkrete Beispiele aus der Praxis, zu geben.
Pro Relaunch
- Pro Relaunch: Georgia.gov
Die Website des US‑Bundesstaats Georgia.gov wurde 2018 komplett neu aufgesetzt. Die alte Software war zu unflexibel und aufwändig zu erweitern. Durch den Relaunch konnte man den Wartungsaufwand deutlich senken und die Nutzerzufriedenheit steigern, bei rund 8 Mio. Besuchen jährlich.
Quelle: https://digital.georgia.gov/case-studies-0/legacy-case-studies/georgiagov-redesign-case-study - Pro Relaunch: Ibotta
Der Umstieg von einer monolithischen Architektur zu einer Microservices-Architektur bei Ibotta erfolgte, um die Wartbarkeit zu verbessern, die Entwicklerproduktivität zu steigern und modernes, skalierbares Software-Design zu ermöglichen. Microservices erlauben eine klare Trennung nach Geschäftsdomänen, erleichtern das Onboarding neuer Entwickler und fördern schnellere, unabhängige Releases durch Containerisierung.
Quelle: https://www.techtarget.com/searchapparchitecture/feature/Developer-search-prompts-a-migration-to-microservices - Pro Relaunch: Spotify
Spotify hat seine Desktop- und Web-Apps in einer gemeinsamen Codebasis vereint, basierend auf der modernen Architektur des Web Players. Ziel war es, Entwicklung zu vereinfachen, Features schneller bereitzustellen und eine einheitliche, barrierefreie Nutzererfahrung zu schaffen. Die neue Plattform erlaubt nun schnellere Innovationen bei gleichbleibender Qualität.
Quelle: https://engineering.atspotify.com/2021/4/building-the-future-of-our-desktop-apps
Andere Standpunkte: Abwägen und Refactoring
- Abwägen: Sunk Cost Fallacy
Man sollte nicht aus Gewohnheit am Altsystem festhalten. Ein Blog-Beitrag von mindtwo warnt ausdrücklich vor der "Legacy-Code zum Selbstzweck"-Falle: Wenn ein System schwer wartbar ist und moderne Anforderungen nur mit großem Aufwand erfüllt, sollte man die Fortführung nicht blind weiterbetreiben. Vielmehr sei eine objektive Bewertung der langfristigen Kosten beider Optionen nötig - unter Berücksichtigung von Wartbarkeit, Entwicklungsgeschwindigkeit und Zukunftsfähigkeit.
Quelle: https://www.mindtwo.de/blog/sunk-cost-fallacy - Contra Relaunch: Code weiterentwickeln
Durch die Neuentwicklung von Code verliert man mitunter jahrelanges Erfahrungswissen. Sascha Thattil rät dagegen zu einer "schrittweisen Verbesserung" der bestehenden Software, weil man bei einer Neuentwicklung "über die Jahre hinweg gewonnene Erkenntnisse verlieren" und damit seinen Wettbewerbsvorteil aufs Spiel setzen kann.
Quelle: https://www.yuhiro.de/sollte-man-bestehende-software-von-grund-auf-neu-schreiben/ - Contra Relaunch: Schulung und Refactoring
In den allermeisten Fällen sei die Antwort auf die Frage "Altes Projekt verwerfen und neu schreiben?" ein deutliches Nein. Ein vollständiges Neuaufsetzen führt oft zu neuem Legacy Code, weil man mit denselben Denkweisen und Ressourcen arbeitet. Stattdessen gibt es die Empfehlung, in Schulung und systematisches Refactoring zu investieren. Refactoring und Code-Qualitätssteigerung seien der "Anfang vom Ende" des Legacy-Problems.
Quelle: https://www.embedded-software-engineering.de/alptraum-legacy-code-wie-profis-damit-umgehen-a-f3e8587edf7944f56718a80df9d78e69/
Wirtschaftliche Kriterien: Wann rechnet sich ein Relaunch wirklich?
Wenn die Kosten für die Bugfixes, die Pflege und die Weiterentwicklung einer alten Codebasis die Vorteile übersteigen, kann ein Relaunch ökonomisch sinnvoller sein als das weitere Stopfen von Löchern. Studien und Erfahrungsberichte liefern dafür greifbare Kennzahlen.
- Wartungskosten als Kostentreiber
In manchen Unternehmen verschlingen Legacy-Systeme zwischen 55 % und 75 % des gesamten IT-Budgets, allein für den Betrieb der alten Anwendung. Typische Wartungskosten steigen jährlich um bis zu 15 %, vor allem durch Technikschulden und Sicherheitsrisiken wie veraltete Bibliotheken, was letztlich auch Compliance-Probleme verursachen kann.
Quelle: https://www.refact.ch/roi - Kostenersparnis durch Re-Engineering gegenüber Neuaufbau
Ein kompletter System-Neuaufbau kann laut CAST Software rund 30 $ pro Code-Zeile kosten, viele Projekte laufen über Budget und Zeit. Nur 16 % der Rewrites bleiben im geplanten Rahmen, über 50 % verzögern sich erheblich oder werden gar nie abgeschlossen. Dagegen spart ein Re-Engineering bestehender Systeme etwa 30 – 40 % der Investitionskosten ein und verkürzt die Time-to-Market durch Wiederverwendung bestehender Komponenten und Funktionalität.
Quellen:
https://hexacorp.com/re-engineering-vs-refactoring-legacy-applications/
https://www.elpassion.com/blog/rewrite-or-refactor-a-balanced-guide-to-legacy-systems
https://codesuite.org/blogs/re-engineering-legacy-apps-is-smarter-and-cheaper-than-starting-from-scratch/ - Return on Investment bei Refactoring
Fallbeispiele zeigen: Werden technische Schulden in einem Projekt zu etwa einem Viertel reduziert, entspricht das auch einem Viertel der jährlichen Teamkosten und die Amortisation erfolgt in etwa einem Jahr, sofern die Wartungskosten ebenfalls entsprechend sinken. Vergleichsstudien belegen auch, dass ein gezieltes Refactoring Wartungsaufwand um 30 – 50 % reduzieren kann, während es Entwickler freisetzt und Fehlerquoten senken hilft.
Quellen:
https://qualilogy.com/en/legacy-application-technical-debt-roi-refactoring/
https://moldstud.com/articles/p-the-importance-of-code-refactoring-in-software-maintenance - Indirekte Kosten: Talentrekrutierung und Entwicklerzufriedenheit
Entwickler verbringen im Schnitt 30 – 40 % ihrer Arbeitszeit damit, Legacy-Code zu verstehen oder zu stabilisieren – in manchen Umgebungen sogar bis zu 57 %. Solche Aufwände führen zu Frustration, sinkender Produktivität und höherer Fluktuation – was sich betriebswirtschaftlich negativ auswirkt.
Quellen:
https://www.sonarsource.com/blog/developers-spend-30-of-their-time-on-code-maintenance-our-latest-survey-results-part-3/
https://www.researchgate.net/publication/293813040_I_Know_What_You_Did_Last_Summer_--_An_Investigation_of_How_Developers_Spend_Their_Time
https://www.techradar.com/pro/devs-are-considering-quitting-en-masse-because-of-embarrassing-legacy-tech-survey-finds
Diese Zahlen belegen eindrücklich, dass Legacy‑Code nicht nur Zeit, sondern auch Motivation und Talent bindet – ein klarer Betriebswirtschaftsfaktor, der für einen Relaunch spricht.
Zusammenfassung: Wann ist ein Relaunch sinnvoll?
Ein Relaunch ist keine spontane Entscheidung, sondern das Ergebnis einer sorgfältigen Abwägung zwischen Kosten, Nutzen und Zukunftsfähigkeit der bestehenden Codebasis.
Die wichtigsten Kriterien im Überblick:
- Wartungskosten: Wenn der Anteil des Budgets für Pflege und Bugfixes auf über 55 % steigt, lohnt sich ein Relaunch meist mehr als endlose Patches.
- Technische Schulden: Veraltete Bibliotheken, monolithische Architekturen und fehlende Dokumentation erhöhen langfristig den Aufwand. Werden mehr als 25 % des Codes ständig umgeschrieben, spricht das für einen Neubau.
- Return on Investment: Ein gut geplanter Relaunch amortisiert sich häufig innerhalb von 6–18 Monaten, dank geringerer Betriebskosten und schnellerer Feature-Releases.
- Time‑to‑Market und Produktivität: Modulare, moderne Architekturen verkürzen Entwicklungszyklen um 30 – 40 %, erlauben schnellere Features und verbessern zugleich die Reaktionsfähigkeit auf Marktanforderungen.
- Skalierbarkeit und Performance: Alte Systeme stoßen bei hohem Traffic oder komplexen Geschäftslogiken oft an ihre Grenzen. Ein Relaunch mit Microservices, Cloud‑Services oder Headless‑Architekturen kann Engpässe auflösen und Performance‑Probleme reduzieren.
- Testbarkeit und Qualitätssicherung: In einer neuen Codebasis lassen sich automatisierte Tests, CI/CD-Pipelines und Code‑Coverage leichter integrieren – für eine höhere Stabilität und weniger Regressionen.
- Entwicklerzufriedenheit: Eine saubere, moderne Code-Umgebung steigert die Motivation und senkt Fluktuation. Entwickler verbringen so nicht mehr bis zu 40 % ihrer Zeit mit Legacy-Code, sondern können sich auf echte Neuerungen konzentrieren.
- Risiko und Sicherheit: Veraltete Softwareplattformen bergen größere Sicherheitsrisiken durch ungepatchte Lücken. Ein Relaunch ermöglicht den Einsatz aktueller Sicherheitsstandards und reduziert Compliance-Aufwände.
Diese Punkte helfen dabei, objektiv abzuwägen, ob ein Relaunch wirtschaftlich sinnvoll und technologisch notwendig ist und wann sich der "saubere Schnitt" wirklich auszahlt.