- Es gibt nicht zwei, sondern drei sinnvolle Wege: gezielt weiterfahren, modernisieren oder neu bauen. Der Neubau wird am häufigsten gefordert und am seltensten sauber begründet.
- Fünf Kriterien tragen die Entscheidung: Änderungskosten pro Feature, Blast Radius, Testbarkeit, Abhängigkeiten und Release-Fähigkeit.
- In Diligence und Board ist nicht die schlechte Codebase das Problem, sondern die fehlende Begründung.
- In drei Arbeitstagen lässt sich die Entscheidung vorbereiten: Landkarte, Befunde mit S/M/L-Aufwand, begründete Empfehlung mit priorisiertem Fix-Backlog.
- Warum die Frage so schwer zu beantworten ist
- Die drei Optionen, nicht zwei
- Fünf Kriterien, die die Entscheidung tatsächlich tragen
- Der Fehler, der bei Diligence und Board am teuersten ist
- Ein Verfahren, das in Tagen statt Monaten entscheidet
- Wie eine tragfähige Empfehlung aussieht
- Typische Fehlentscheidungen
- Fazit
- Häufige Fragen
1. Warum die Frage so schwer zu beantworten ist
Bei einer gewachsenen JS/TS-Codebase fehlt fast immer die eine Zahl, die die Entscheidung tragen würde: Wie viel Aufwand steckt in welchem Teil? Stattdessen gibt es drei Meinungen. Die einen sagen "das ist alles Altlast", die anderen "es läuft doch", und dazwischen sitzt jemand, der es am besten wüsste, aber keine Zeit hat, es aufzuschreiben.
Dazu kommt ein struktureller Bias. Wer die Codebase geschrieben hat, neigt zum Behalten. Wer neu im Team ist, neigt zum Neubau. Wer das Budget verwaltet, neigt zur günstigeren Variante - und die sieht fast immer nach "weiterlaufen lassen" aus, weil der Neubau zuerst Geld kostet und erst später spart. Wie sich dieser aufgeschobene Aufwand über die Jahre ansammelt, beschreibt Technische Schulden abbauen.
2. Die drei Optionen, nicht zwei
In der Praxis gibt es nicht zwei, sondern drei sinnvolle Wege:
Gezielt weiterfahren. Die Architektur trägt, die Probleme sind lokal begrenzt. Man räumt an definierten Stellen auf und liefert weiter.
Modernisieren. Die Grundstruktur bleibt, aber zentrale Teile werden ersetzt: Build, Typisierung, Abhängigkeiten, Datenzugriff, Testabdeckung an den kritischen Stellen.
Neu bauen. Die Anforderungen haben sich so verändert, dass die bestehende Struktur jede Änderung teurer macht als ein Neuanfang - und der Bestand sich in absehbarer Zeit ablösen lässt.
| Option | Wann sie trägt | Was passiert |
|---|---|---|
| Gezielt weiterfahren | Die Architektur trägt, die Probleme sind lokal begrenzt | Aufräumen an definierten Stellen, weiter liefern |
| Modernisieren | Die Grundstruktur bleibt tragfähig | Build, Typisierung, Abhängigkeiten, Datenzugriff und Tests an kritischen Stellen werden ersetzt |
| Neu bauen | Die Struktur macht jede Änderung teurer als ein Neuanfang | Parallelbetrieb, Datenmigration, Ablösung des Bestands |
Die dritte Option wird am häufigsten gefordert und am seltensten sauber begründet. Deshalb ist sie die, die am strengsten geprüft gehört.
3. Fünf Kriterien, die die Entscheidung tatsächlich tragen
1. Änderungskosten pro Feature. Wie lange dauert ein durchschnittliches Feature heute im Vergleich zu vor zwei Jahren? Wenn die Zeit steigt, während das Team gleich bleibt, ist das ein Messwert - keine Stimmung.
2. Blast Radius. Wie viele Dateien muss man anfassen, um eine Kleinigkeit zu ändern? Ein Feature, das 40 Dateien berührt, sagt mehr über die Struktur als jede Code-Review-Meinung.
3. Testbarkeit. Gibt es Bereiche, die man nicht testen kann, ohne die halbe Anwendung zu starten? Alles, was sich nicht isoliert prüfen lässt, wird bei jeder Änderung zum Risiko.
4. Abhängigkeiten. Wie viele Bibliotheken sind veraltet, wie viele werden nicht mehr gepflegt, wie viele haben bekannte Sicherheitsprobleme? Das ist ein harter, listenfähiger Befund. Ein typischer Fall ist die Laufzeit selbst, wie Node.js-Upgrade: Risiko, Planung, Budget zeigt.
5. Release-Fähigkeit. Lässt sich heute ein Release in einem Schritt bauen und ausliefern, oder braucht es Handarbeit? Das ist der Punkt, der vor einem Release oder einer Board-Frage am meisten weh tut.
4. Der Fehler, der bei Diligence und Board am teuersten ist
In Prüfungssituationen ist nicht die schlechte Codebase das Problem, sondern die fehlende Begründung. Ein Prüfer fragt nicht "Ist der Code gut?", sondern "Warum ist das die richtige Entscheidung, und was kostet die Alternative?". Worauf Käufer dabei sonst noch achten, steht in Technische Due Diligence.
Für die Prüfungssituation: Wer nur eine Meinung hat, verliert Zeit. Wer eine priorisierte Liste hat - welche Teile tragfähig sind, welche nicht, was der Fix pro Position kostet - kann die Frage in einer Sitzung beantworten.
5. Ein Verfahren, das in Tagen statt Monaten entscheidet
Statt eine Grundsatzdebatte zu führen, lässt sich die Entscheidung in drei Arbeitstagen vorbereiten:
Tag 1 - Landkarte. Module, Abhängigkeiten, Build, Datenzugriff und die Stellen, an denen Änderungen regelmäßig hängen bleiben.
Tag 2 - Befunde und Aufwand. Jeder Befund wird belegt und in S/M/L eingestuft: Was ist in Stunden erledigt, was in Tagen, was nur als eigenes Vorhaben.
Tag 3 - Empfehlung. Eine begründete Option - weiterfahren, modernisieren oder neu bauen - mit priorisiertem Fix-Backlog und einer Entscheidungsrunde, in der die Fragen gestellt werden dürfen, die bisher niemand beantworten konnte.
Genau für diese Konstellation gibt es bei Kigazon die Codebase-Entscheidung in 3 Tagen für gewachsene JS/TS-Codebases: eine Empfehlung vor Release, Diligence oder Board, ein priorisiertes Fix-Backlog in S/M/L und eine Entscheidungsrunde - zum Festpreis.
6. Wie eine tragfähige Empfehlung aussieht
Eine gute Empfehlung nennt drei Dinge.
Was jetzt entschieden werden muss. Nicht alles, was man reparieren könnte, sondern der Teil, ohne den der nächste Schritt nicht möglich ist.
Was es kostet, nichts zu entscheiden. Das ist die entscheidende Zahl für jede Budgetdiskussion: Wo landet der Aufwand, wenn die Struktur bleibt?
Was die Alternative wirklich kostet. Neubau heißt nicht Null. Er heißt zwei Systeme parallel betreiben, Daten migrieren, Nutzer mitnehmen - und während dieser Zeit nicht oder eingeschränkt liefern.
7. Typische Fehlentscheidungen
- Neubau ohne Migrationsplan. Der teuerste Teil des Neubaus ist nicht das Bauen, sondern das Umziehen.
- Modernisieren ohne Zielbild. Ohne feste Reihenfolge wird jede Stelle einzeln angefasst, und am Ende hat man dieselbe Struktur mit neueren Bibliotheken.
- Weiterlaufen ohne Zahlen. "Es läuft doch" ist keine Begründung, solange niemand weiß, was eine Änderung heute kostet.
- Prüfung ohne die Leute, die den Code kennen. Wer die Befunde nicht mit dem Team prüft, bekommt ein Papier, das niemand mitträgt.
Wie sich ein Bestand schrittweise ablösen lässt, statt alles auf einmal umzuziehen, beschreibt das Strangler Fig Pattern. Und wenn das Wissen über den Code nur bei einer Person liegt, ist das ein eigenes Risiko, das der Bus-Faktor beschreibt.
Fazit
Die Entscheidung "modernisieren oder neu bauen" ist keine Geschmacksfrage, sondern eine Rechnung, die man belegen kann: Änderungskosten, Blast Radius, Testbarkeit, Abhängigkeiten, Release-Fähigkeit. Wer diese fünf Kriterien mit Zahlen hinterlegt, entscheidet in Tagen statt in Quartalen - und kann die Entscheidung vor Release, Diligence oder Board verteidigen.
Wenn Sie die Umsetzung danach nicht allein tragen wollen, unterstützt Sie professionelle Softwareentwicklung beim Modernisieren oder Neubau, und ein Interim CTO hilft, die Entscheidung im Team und gegenüber dem Board zu vertreten.