Die versteckten Kosten veralteter Software

Software, die seit acht Jahren zuverlässig Rechnungen schreibt, gilt in vielen Vorstandsrunden als Problemfall. Dabei ist genau das Gegenteil der Fall: Ein System, das jahrelang läuft, ist der Beweis, dass die Fachlogik funktioniert. Das eigentliche Problem sind selten die Geschäftsregeln, die darin stecken — sondern der Code drumherum, die veraltete Umgebung und die Abhängigkeiten, die niemand mehr aktualisiert hat.

Die Kosten veralteter Software sind trotzdem real. Sie stehen nur nicht in der Bilanz. Sie verstecken sich in Wartungsstunden, verpassten Terminen und Risiken, die erst sichtbar werden, wenn es zu spät ist. Dieser Artikel zeigt, wo diese Kosten tatsächlich entstehen — und warum eine komplette Neuentwicklung meist die teuerste Antwort auf die falsche Frage ist.

Was kostet veraltete Software wirklich — jenseits der Lizenzgebühren?

Die sichtbaren Kosten veralteter Software sind der kleinere Teil. Teuer wird das, was im Tagesgeschäft langsam versickert. Diese Kostenblöcke tauchen in fast jedem Legacy-Projekt auf:

• Wartungsreibung: Jede kleine Änderung dauert länger, weil niemand mehr sicher weiß, welche Nebenwirkung sie auslöst. Was in einem sauberen System eine Stunde wäre, wird zum Tagesprojekt mit manuellem Testen.
• Wissensmonopole: Oft kennt nur eine einzige Person die kritischen Stellen. Fällt sie aus oder kündigt sie, wird jede Anpassung zum Risiko.
• Aufgeschobene Sicherheitslücken: Läuft die Anwendung auf PHP 5.6 oder 7.2, gibt es seit Jahren keine Security-Patches mehr. Jede bekannte Lücke bleibt offen.
• Blockierte Weiterentwicklung: Neue Anforderungen aus dem Vertrieb oder von Kunden lassen sich nicht mehr umsetzen, weil das System sie technisch nicht hergibt.

Keiner dieser Posten erscheint als Rechnung. Zusammen kosten sie oft mehr als eine Modernisierung — nur eben verteilt über Jahre und über viele Köpfe, sodass niemand die Summe zieht.

Warum ist alter Code nicht dasselbe wie schlechte Software?

Hier liegt das größte Missverständnis. Ein zehn Jahre altes System wird gerne pauschal als "Altlast" abgestempelt. Doch die Fachlogik darin — wie ein Rabatt berechnet wird, welche Prüfungen ein Auftrag durchlaufen muss, wie Steuern korrekt ausgewiesen werden — ist über Jahre in der Praxis gehärtet worden. Diese Regeln funktionieren, weil echte Kunden und echte Grenzfälle sie geformt haben.

Das Problem sitzt fast immer in der Schicht darum herum: veraltete PHP-Version, keine automatisierten Tests, direkt zusammengemischte SQL-Abfragen im View, ein selbstgebautes Framework aus 2013, das niemand mehr pflegt. Das ist ärgerlich, aber es ist reparierbar. Die wertvolle Fachlogik ist meist zu retten, wenn man sie sauber freilegt, statt sie wegzuwerfen.

Ein typisches Beispiel aus der PHP-Welt

Eine Anwendung läuft auf PHP 7.2 mit einem alten Symfony 2 oder einem eigenen Framework. Die Datenbankzugriffe stehen als rohe mysqli-Queries mitten im Template. Es gibt keinen einzigen automatisierten Test. Solange nichts geändert werden muss, läuft alles. Sobald aber eine neue Schnittstelle gebraucht wird oder der Hoster PHP 7.2 abschaltet, steht das Team vor einer Wand — nicht wegen der Geschäftsregeln, sondern wegen der Umgebung.

Warum ist die Neuentwicklung meist die teuerste Option?

Eine komplette Neuentwicklung wirkt sauber, ist aber in der Regel die riskanteste und teuerste Variante. Der Grund: Sie werfen dabei nicht nur den schlechten Code weg, sondern auch die gesamte gehärtete Fachlogik — jahrelang bewährtes Wissen, das oft nirgends dokumentiert ist, sondern nur im Code lebt.

Neuentwicklungen scheitern selten am Anfang. Sie scheitern in der Mitte, wenn all die Sonderfälle auftauchen, die im alten System längst gelöst waren und die niemand mehr auf dem Schirm hatte. Typische Muster:

1. Das neue System deckt 80 Prozent ab, aber die letzten 20 Prozent Grenzfälle kosten mehr als die ersten 80.
2. Während der Neuentwicklung muss das alte System parallel weiter gepflegt werden — Sie zahlen doppelt.
3. Der Umschalttermin verschiebt sich, das Vertrauen bröckelt, und am Ende läuft das Alt-System noch Jahre weiter.

Das heißt nicht, dass eine Neuentwicklung nie richtig ist. Wenn sich das Geschäftsmodell grundlegend geändert hat und die alte Logik gar nicht mehr passt, kann sie sinnvoll sein. Aber sie sollte die bewusste Ausnahme sein, nicht der Reflex.

Wie senkt man die Kosten veralteter Software ohne Totalumbau?

Der pragmatische Weg ist die schrittweise Modernisierung. Sie halten das System durchgehend lauffähig und reduzieren Risiko und Kosten in kleinen, überprüfbaren Schritten. Bewährt hat sich diese Reihenfolge:

• Erst absichern, dann anfassen: Bevor Sie irgendetwas ändern, schreiben Sie Tests für das kritische Verhalten. Sogenannte Characterization Tests halten fest, was das System heute tut — so merken Sie sofort, wenn ein Umbau etwas kaputt macht.
• PHP-Version anheben: Der Sprung auf eine aktuelle, unterstützte PHP-Version bringt Sicherheits-Patches zurück und ist oft mit Werkzeugen wie Rector teilautomatisierbar.
• Fachlogik entkoppeln: Die Geschäftsregeln aus Templates und Controllern herauslösen, damit sie testbar und wiederverwendbar werden.
• Schrittweise ersetzen: Nach dem Strangler-Fig-Muster ersetzen Sie einzelne Bereiche nacheinander, während der Rest weiterläuft. Kein Big-Bang-Termin, kein Alles-oder-nichts.

Der entscheidende Punkt: Bei diesem Vorgehen liefert das System zu jedem Zeitpunkt Wert. Sie können nach jedem Schritt aufhören, und trotzdem ist die Anwendung sicherer und wartbarer als vorher.

Woran erkennen Sie, dass es sich lohnt zu handeln?

Nicht jedes alte System muss angefasst werden. Ein stabiles, isoliertes Tool, das seine Aufgabe erfüllt und nie geändert werden muss, dürfen Sie in Ruhe lassen. Handeln lohnt sich, wenn mehrere dieser Punkte zutreffen:

• Die PHP-Version wird bald vom Hoster abgeschaltet oder erhält keine Sicherheits-Updates mehr.
• Änderungen dauern spürbar länger und niemand traut sich mehr an bestimmte Stellen.
• Es gibt keine Tests, sodass jede Anpassung ein Blindflug ist.
• Das Wissen hängt an einer einzigen Person.
• Neue Geschäftsanforderungen scheitern regelmäßig an der Technik.

Ehrlicher Praxis-Tipp: Bevor Sie über Neuentwicklung oder Modernisierung entscheiden, lassen Sie den kritischsten Ablauf im System mit einem Test absichern und die PHP-Version prüfen. Diese zwei Schritte kosten wenig, machen die tatsächlichen Kosten veralteter Software sichtbar und verhindern die teuerste Fehlentscheidung — den Reflex zum Neuanfang. Genau bei dieser nüchternen Einschätzung und der schrittweisen Rettung von Legacy-PHP-Anwendungen unterstützt LegacyWerk.