Die Frage wird selten früh gestellt. Meistens kommt sie, wenn eine Kleinigkeit unerwartet lange gedauert hat, wenn ein Sicherheitsupdate ansteht oder wenn der bisherige Entwickler angekündigt hat, dass er aufhört. Dann steht sie plötzlich im Raum, und es soll schnell eine Antwort her.
Die naheliegende Antwort ist meistens falsch. Ein altes System wirkt nach Neubau, und ein teures Angebot wirkt nach Sanieren. Beides sind Bauchentscheidungen.
Drei Wege, nicht zwei
Die Gegenüberstellung von Neubau und Sanierung übersieht den Weg, der in der Mehrzahl der Projekte gewinnt: die schrittweise Ablösung. Das neue System übernimmt einen Bereich nach dem anderen, das alte läuft daneben weiter und wird nach und nach kleiner.
Ob dieser Weg offensteht, entscheidet sich an einer einzigen Frage. Lässt sich das alte System an einer sinnvollen Stelle aufschneiden, ohne dass alles wackelt?
Wenn Sanieren reicht
Sanieren ist richtig, wenn der fachliche Kern noch stimmt und nur die Umgebung veraltet ist. Das erkennt man daran, dass die Begriffe im System noch die Begriffe des Geschäfts sind. Ein Auftrag heißt Auftrag und verhält sich wie einer, eine Rechnung ebenso.
Dann bleibt der Aufbau, und erneuert werden Version, Abhängigkeiten, Oberfläche und die Stellen, an denen sich Schulden angesammelt haben. Das ist unspektakulär, planbar und in Etappen möglich, bei denen das System nach jeder lauffähig bleibt. Wie so ein Versionssprung abläuft, steht unter Laravel-Versionen und Upgrade.
Wenn nur ein Neubau bleibt
Für einen Neubau spricht ein einziger Befund wirklich: Das fachliche Modell stimmt nicht mehr. Das System kennt keinen Vorgang, den Ihr Geschäft seit Jahren hat, und die Leute behelfen sich mit Umwegen, die im Programm anders heißen als in der Wirklichkeit. Wenn eine Reklamation als Auftrag mit negativer Menge und dem Kürzel im Bemerkungsfeld erfasst wird, ist das kein Schönheitsfehler, sondern ein Modell, das an der Sache vorbeigeht.
Zwei weitere Gründe kommen vor und wiegen schwerer, als sie klingen. Die Technik ist tot, weil es für die Sprache, das Framework oder die Datenbank keine Sicherheitsdeckung mehr gibt und niemand mehr damit arbeiten will. Oder es gibt keinen Zugang mehr zum Quellcode. Dann ist die Entscheidung ohnehin getroffen.
Warum der mittlere Weg meistens gewinnt
Ein Neubau am Stück hat einen Tag, an dem alles gleichzeitig funktionieren muss. Bis dahin läuft die Weiterentwicklung des alten Systems weiter, weil der Betrieb nicht stillsteht, und das neue System jagt einem Ziel hinterher, das sich bewegt. Projekte scheitern selten an der Technik, sondern an dieser Gleichzeitigkeit.
Der schrittweise Weg tauscht dieses Risiko gegen Aufwand. Er braucht eine Grenze zwischen alt und neu, über die beide Seiten miteinander reden, und er braucht eine Regel, welches System für welche Daten zuständig ist. Diese Grenze zu bauen, kostet Zeit, die bei einem Neubau nicht anfällt. Dafür ist nach jeder Etappe etwas fertig, und das Vorhaben lässt sich anhalten, ohne dass alles verloren ist.
Woran die Entscheidung wirklich hängt
Nicht am Alter des Codes. Es gibt zwölf Jahre alte Anwendungen, die sich hervorragend weiterentwickeln lassen, und drei Jahre alte, bei denen jede Änderung ein Risiko ist.
Sie hängt am Zustand des fachlichen Modells, an der Frage, ob sich das System aufschneiden lässt, und daran, wie viel Weiterentwicklung während der Umstellung nötig ist. Diese drei Punkte lassen sich in wenigen Tagen klären, und sie zu klären ist deutlich billiger, als sie zu raten.
Wie wir dabei vorgehen, steht unter Softwaremodernisierung.
