Das Projekt das niemand stoppen wollte
Nach einer Fusion gibt es immer denselben Moment. Zwei Unternehmen, zwei Infrastrukturen, zwei Codebases, zwei Arten zu arbeiten. Und irgendwann sitzt jemand im C-Level und sagt: Wir müssen das konsolidieren. Wir müssen Synergien nutzen. Wir brauchen eine einheitliche Plattform.
Was folgte war ein Rewrite. Komplett neu. Die gesamte SaaS-Infrastruktur, einheitlich in Go als Microservices. Rund 50 Entwickler, verteilt auf Teams rund um die Welt, sollten in einem Schritt eine neue Architektur bauen, eine neue Sprache lernen und gleichzeitig den laufenden Betrieb nicht gefährden.
Sechs Monate später wurde das Projekt eingestellt. Ein neuer CEO hatte andere Prioritäten.
Das System das ersetzt werden sollte läuft heute noch.
Warum Rewrites so verlockend sind
Die Logik hinter einem Full-Rewrite ist immer dieselbe und sie klingt immer vernünftig. Der bestehende Code ist gewachsen, schwer wartbar, voller technischer Schulden. Neue Anforderungen lassen sich nur mit Mühe integrieren. Das Team verliert Zeit mit Legacy-Code statt an Features zu arbeiten. Ein Neustart würde alles besser machen.
Das ist nicht falsch. Gewachsene Systeme haben echte Probleme. Technische Schulden sind real. Und manchmal ist der Wunsch nach einem sauberen Blatt Papier vollkommen verständlich.
Das Problem ist nicht die Diagnose. Das Problem ist die Therapie.
Ein Full-Rewrite ist die radikalste mögliche Antwort auf ein Problem das in den meisten Fällen eine graduelle Lösung verträgt. Und radikale Antworten haben radikale Risiken die in der Planungsphase systematisch unterschätzt werden.
Was wirklich passiert wenn man neu anfängt
Das erste was beim Rewrite unterschätzt wird ist wie viel Wissen im bestehenden System steckt das nirgendwo dokumentiert ist. Edge Cases die irgendwann aufgetaucht sind und still behoben wurden. Business-Logik die in tausend kleinen Entscheidungen steckt. Integrationen mit externen Systemen die sich anders verhalten als ihre Dokumentation behauptet. Dieses implizite Wissen muss beim Rewrite nicht einmal neu erarbeitet werden – sondern immer wieder wenn die neue Codebase auf dieselben Probleme trifft die das alte System bereits gelöst hatte.
Das wäre alleine schon schwierig genug. In dem Projekt das ich erlebt habe kam hinzu dass nicht nur neu geschrieben wurde – es wurden gleichzeitig eine neue Sprache eingeführt, eine neue Architektur etabliert und ein globales Team koordiniert das noch nie so zusammengearbeitet hatte. Jedes dieser Vorhaben wäre für sich genommen eine Herausforderung gewesen. Zusammen multiplizierten sie sich gegenseitig auf eine Art die in keinem Projektplan auftaucht.
Go war für viele Entwickler neu. Das kostet Zeit – nicht nur zum Lernen der Syntax sondern zum Verstehen idiomatischer Patterns, der Concurrency-Modelle, der operativen Eigenheiten die erst in Produktion sichtbar werden. Microservices als Architektur bedeuteten dass Entscheidungen die vorher lokal getroffen werden konnten plötzlich teamübergreifende Abstimmung erforderten. Und 50 Entwickler in verschiedenen Zeitzonen bedeuteten dass diese Abstimmung täglich Stunden kostete die nicht in Code flossen. Die Geschwindigkeit des Projekts war von Anfang an nicht durch technische Probleme begrenzt – sondern durch Koordinationsaufwand.
Und dann ist da noch die Zeit. Ein laufendes System liefert täglich Wert. Ein Rewrite liefert monatelang nichts. Je länger er dauert desto größer wird die Lücke zwischen dem was das alte System bereits kann und dem was das neue noch nicht kann. Und desto schwieriger wird es den Rewrite intern zu rechtfertigen – gegenüber einem Management das Ergebnisse sehen will, gegenüber einem neuen CEO der das Projekt nicht kennt und nicht verteidigen muss.
Der organisatorische Overhead den niemand einplant
Was in Planungsdokumenten oft fehlt ist die Reibung die entsteht wenn viele Menschen an einem unscharfen Ziel arbeiten. Ein Full-Rewrite ist per Definition ein Projekt mit hoher Unsicherheit. Die Anforderungen sind nicht vollständig bekannt weil sie im bestehenden System stecken. Die Architektur entwickelt sich während des Projekts. Entscheidungen werden getroffen, revidiert, neu getroffen.
In einem kleinen Team ist das handhabbar. In einem Team von 50 Entwicklern über mehrere Zeitzonen hinweg wird jede Unklarheit zur Blockade. Abstimmungsmeetings fressen Zeit. Missverständnisse entstehen weil die Kommunikationsbandbreite zwischen Zeitzonen begrenzt ist. Teams warten aufeinander.
Hinzu kommt die politische Dimension. Nach einer Fusion kämpfen Teams um Einfluss auf die neue Architektur. Entscheidungen werden nicht nur nach technischen Kriterien getroffen sondern auch nach organisatorischen. Das verlangsamt alles weiter.
Und dann kommt ein neuer CEO.
Warum das alte System überlebt
Das System das ersetzt werden sollte läuft heute noch. Das ist kein Zufall und kein Versagen – es ist die logische Konsequenz davon dass das bestehende System über Jahre optimiert wurde für genau die Probleme die es jeden Tag löst.
Gewachsene Systeme sind oft hässlich. Sie haben technische Schulden. Sie sind schwer zu verstehen für jemanden der neu ins Team kommt. Aber sie laufen. Sie liefern täglich Wert. Und sie haben implizites Wissen das kein Rewrite in einem Jahr nachbauen kann.
Das bedeutet nicht dass man Legacy-Systeme nie modernisieren sollte. Es bedeutet dass Full-Rewrites in den meisten Fällen die falsche Antwort sind.
Was stattdessen funktioniert
Die Alternative zum Full-Rewrite ist nicht Stillstand. Es ist schrittweise Modernisierung mit klaren Grenzen und messbaren Ergebnissen – und ich habe erlebt wie gut das funktionieren kann.
In einem anderen Projekt wurde ein neues Team aus einer großen bestehenden Organisation herausgelöst. Die Aufgabe war dieselbe die viele Teams kennen: eine gewachsene PHP-Codebase übernehmen und modernisieren. Der Unterschied war der Ansatz. Statt alles neu zu schreiben übernahm ich die bestehende Codebase und begann sie schrittweise zu modularisieren. Abhängigkeiten wurden identifiziert und aufgelöst. Logik wurde gekapselt. Module wurden entkoppelt bis sie eigenständig testbar und deploybar waren.
Das Ziel war nicht Perfektion sondern Beweglichkeit. Jedes Modul das sauber abgegrenzt war konnte unabhängig auf PHP 8 migriert werden ohne den Rest des Systems zu gefährden. Das System das vorher monolithisch unter PHP 7.1 lief wurde schrittweise und ohne einen einzigen großen Schnitt auf eine moderne Basis gehoben – während es die ganze Zeit in Produktion lief und Wert lieferte.
Das dauerte länger als ein Rewrite auf dem Papier. In der Praxis war es schneller weil es nie komplett zum Stillstand kam. Nach drei Monaten liefen erste Module bereits auf PHP 8. Nach sechs Monaten war ein Großteil der kritischen Logik migriert. Es gab keinen Moment wo das Management hätte fragen können: Wann seht ihr endlich Ergebnisse? Die Ergebnisse waren jede Woche sichtbar.
Das ist der fundamentale Unterschied zum Full-Rewrite. Ein schrittweiser Ansatz verteilt das Risiko, gefährdet das laufende System nie und liefert kontinuierlich Wert während die Modernisierung läuft. Er ist politisch robuster weil er nicht auf einen einzigen großen Moment wartet der nie kommt – sondern jeden Monat kleine Momente liefert die schwer zu ignorieren sind.
Was das Projekt wirklich gelehrt hat
Das Projekt wurde eingestellt weil ein neuer CEO andere Prioritäten hatte. Das klingt nach Pech. Es war auch Struktur.
Ein Projekt das sechs Monate läuft ohne sichtbare Ergebnisse ist angreifbar. Ein neues Management muss es nicht verstehen und nicht verteidigen. Es kann es einstellen – und das ist rational.
Ein schrittweiser Modernisierungsansatz hätte nach sechs Monaten sichtbare Ergebnisse geliefert. Einzelne Services neu gebaut. Messbare Performance-Verbesserungen. Code der bereits in Produktion läuft und Wert liefert. Das ist schwerer einzustellen weil es schwerer zu ignorieren ist.
Full-Rewrites scheitern nicht nur an Technologie. Sie scheitern weil sie zu lange zu viel versprechen ohne zu liefern. Und in einer Welt in der Prioritäten sich ändern – durch neue CEOs, durch Marktveränderungen, durch Budgetdruck – ist das ein strukturelles Risiko das kein technisches Design lösen kann.
Das System das ersetzt werden sollte läuft heute noch. Das ist nicht tragisch. Es ist lehrreich.
