Beantwortet von Matthias Hinsche Stand
Die Entscheidung wird oft aus dem Bauch getroffen, weil ein System „alt aussieht”. Alt aussehen ist der schlechteste aller Gründe.
Die fünf Prüfpunkte
1. Stimmt die Fachlogik noch? Bildet das System ab, wie ihr heute arbeitet? Wenn ja, steckt darin jahrelanges Wissen über Sonderfälle, das ein Neubau erst wieder einsammeln müsste.
2. Läuft die Technik noch mit Sicherheitsupdates? Eine nicht mehr unterstützte Programmiersprache, ein Datenbanksystem ohne Patches oder ein Server, der nicht mehr aktualisiert werden kann, sind harte Argumente.
3. Versteht noch jemand den Code? Wenn die Person, die das System gebaut hat, seit Jahren weg ist und keine Dokumentation existiert, ist jede Änderung teuer und riskant.
4. Wie oft ändert sich etwas? Ein System, das seit fünf Jahren unverändert läuft und weiter passt, braucht keinen Neubau. Eines, an dem monatlich gearbeitet wird, profitiert von einer besseren Basis.
5. Gibt es Tests? Ohne automatisierte Tests ist eine Modernisierung riskanter, weil niemand merkt, wenn etwas kaputtgeht.
Der dritte Weg, der oft übersehen wird
Schrittweise ablösen. Statt alles auf einmal neu zu bauen, wird das Altsystem nach und nach umbaut: Neue Funktionen entstehen außerhalb, greifen aber auf die alten Daten zu. Über Monate wandert Funktion für Funktion, das Altsystem schrumpft.
Der Vorteil: Es gibt keinen Stichtag, an dem alles gleichzeitig funktionieren muss. Genau dieser Stichtag ist es, an dem Neubauten scheitern.
Warum ein Neubau selten der Königsweg ist
Er dauert länger als geplant, und währenddessen wird das Altsystem nicht weiterentwickelt. Fachlich entsteht in dieser Zeit ein Rückstand. Und die Sonderfälle, die im alten Code stecken, tauchen erst nach dem Umstieg wieder auf.
Wie du den Zustand belastbar bewertest, steht in Was sind technische Schulden?. Beratung: Individuelle Softwareentwicklung.