Technische Schulden und veraltete Komponenten um jeden Preis zu vermeiden, klingt nach der richtigen Haltung. Für Software am Lebensende ist es das aber nicht zwangsläufig. Wenn eine Anwendung sich dem Ende ihres Lebenszyklus nähert, wird die Frage nach dem richtigen Umgang mit Updates plötzlich zu einer wirtschaftlichen Abwägung, nicht zu einer rein technischen. Wer diese Abwägung bewusst trifft, spart Geld, ohne unkalkulierbare Risiken einzugehen.

Der Normalfall: Updates gehören zur Wartung

Bei Anwendungen, die seit Jahren produktiv und unternehmensrelevant im Einsatz sind, ist der Umgang mit Updates eingespielt. Stehen Aktualisierungen für zentrale Komponenten an, etwa für die eingesetzten Frameworks und Bibliotheken, werden sie zeitnah durchgeführt. So sind bei bekannt gewordenen Sicherheitslücken, den sogenannten CVEs, immer die notwendigen Korrekturen verfügbar. Werkzeuge, die den Aktualisierungsstand aller Abhängigkeiten sichtbar machen, zeigen sofort, wo etwas ansteht. Bei Bedarf und passendem Budget wird dann ein technisches Update-Release eingeplant.

So weit die Theorie, die für den Großteil der Laufzeit einer Anwendung auch richtig ist. Diese laufende Pflege ist nichts anderes als das Abtragen technischer Schulden, bevor sie sich auftürmen. Interessant wird es erst, wenn ein Ende absehbar ist.

Wenn das Ende absehbar ist

Der Fall aus der Praxis: Eine seit vielen Jahren produktive Anwendung nähert sich dem Ende ihres Lebenszyklus. Nicht, weil jemand alles neu machen möchte, sondern weil der zugrundeliegende Anwendungsfall in einigen Jahren schlicht nicht mehr existieren wird. Damit ändert sich die Ausgangslage für jede Update-Entscheidung.

Aus rein technischer Sicht will man sofort aktualisieren. Sauberer Code, aktuelle Abhängigkeiten, alles auf dem neuesten Stand, fast eine Frage der Ehre. Mit dem Blick des Geschäfts sieht das anders aus. Dort stellt man nüchtern den Aufwand für Updates den Kosten für Extended Support gegenüber. Und beim Aufwand zählt nicht nur das nächste große Versionsupdate, sondern jedes weitere bis zum geplanten Laufzeitende. Aus einer einzelnen Aktualisierung wird schnell eine Kette wiederkehrender Update-Releases, die alle bezahlt werden wollen.

Drei Optionen für die Restlaufzeit

Für Software am Lebensende gibt es im Kern drei Wege, und jeder hat seinen Preis.

• Updates durchführen: der saubere Weg, technisch einwandfrei, aber teuer. Und der Aufwand fällt wiederkehrend an, bis zum Schluss.
• Extended Support buchen: ein Anbieter kümmert sich weiter um Sicherheitskorrekturen für eine ältere Version, gegen Bezahlung. Die Anwendung wird dabei nicht weiterentwickelt, sondern nur abgesichert.
• Bewusst mit dem Restrisiko leben: darauf setzen, dass bis zum Laufzeitende keine kritischen Sicherheitslücken mehr auftreten. Günstig, aber riskant.

Die dritte Option klingt nach Glücksspiel, und das ist sie auch. Aber bei begrenzter Restlaufzeit und überschaubarem Risiko kann selbst das eine bewusste, wirtschaftlich vertretbare Entscheidung sein. Entscheidend ist, dass sie bewusst getroffen wird und nicht aus Nachlässigkeit entsteht. Der Unterschied zwischen einer kalkulierten Risikoentscheidung und schlichtem Ignorieren ist gewaltig.

Warum Wartung eine wirtschaftliche Frage ist

Wie teuer das Ignorieren wird, zeigt der Vergleich zweier Kunden. Beim ersten wurde eine Anwendung über Jahre fachlich weiterentwickelt, Feature für Feature, Wunsch für Wunsch. Für technische Wartung war selten Zeit, „machen wir später“ hieß es, aber später kam nie. Abhängigkeiten wurden nur aktualisiert, wenn eine Sicherheitslücke keine Wahl ließ, Workarounds blieben Workarounds, die technischen Schulden wuchsen. Sechs Monate später merkt man das in der Entwicklung, zwölf Monate später spüren es die Nutzer. Sie kennen jede Ecke und jeden Kniff, mit dem es nicht hakt, zufrieden sind sie trotzdem nicht.

Kommt dann eine neue Sicherheitslücke, geht das Versionsupdate nicht mehr schnell nebenbei. Andere Abhängigkeiten sind zu alt, große Updates müssen nachgezogen werden, und plötzlich kostet das ein Vielfaches. Jedes neue Feature dauert gefühlt doppelt so lange, weil man sich erst durch den Wildwuchs arbeiten muss. Das Wissen darüber, wo die Fallstricke liegen, steckt in wenigen Köpfen. Und die guten Leute verlieren die Lust, denn niemand will dauerhaft Brände aus der Vergangenheit löschen.

Beim zweiten Kunden läuft es umgekehrt. Sicherheitslücken werden in wenigen Tagen behoben, Aktualisierungen laufen regelmäßig und weitgehend automatisiert mit, verfügbare Updates werden proaktiv eingespielt. Dieser Kunde hat sogar einen kompletten Wechsel der technischen Basis angestoßen, weg von einer in die Jahre gekommenen, komplexen Lösung hin zu einer schlanken, gut wartbaren Anwendung, und die Datenbank gleich mit aufgeräumt. Seine Vorgabe: sich auf eine einzige Anwendung reduzieren und die in erstklassigem Zustand betreiben. Das hat Geld gekostet. Heute ist der monatliche Wartungsaufwand deutlich gesunken, Änderungen gehen schneller in Produktion, die Lizenzkosten sind niedriger und die bekannten Risiken liegen nahe null.

Der Unterschied zwischen beiden Projekten liegt nicht am Team, nicht an der Technologie und nicht am Budget. Er liegt in der Haltung des Geschäfts. Einmal wird gespart, wo es geht, und technische Maßnahmen verlieren immer gegen das nächste Feature. Im anderen Fall ist klar, dass eine Anwendung zwei Seiten hat, eine fachliche und eine technische, und dass beide Pflege brauchen. Softwarequalität ist damit keine technische Frage, sondern eine wirtschaftliche. Wer heute an der Wartung spart, zahlt morgen Zinsen.

Fazit

Für Software am Lebensende gibt es keine pauschal richtige Antwort. Updates, Extended Support und ein bewusst getragenes Restrisiko sind alle legitim, solange die Entscheidung mit Blick auf Restlaufzeit, Aufwand und Risiko bewusst getroffen wird. Der eigentliche Fehler ist nicht, sich gegen das teure Update zu entscheiden. Der eigentliche Fehler ist, gar nicht zu entscheiden und die Wartung so lange zu vertagen, bis aus einer überschaubaren Aufgabe ein teurer Sanierungsfall wird.