Technische Schulden: Die versteckten Kosten aufgeschobener IT-Upgrades

„Wir sind nur einen kritischen Security-Incident von einer Katastrophe entfernt“. Dies ist die Aussage eines IT-Architekten, der sich um seine Applikationen sorgt. Warum kam es zu diesem Statement? Es wurde auf höherer Ebene entschieden, die Upgrades zu pausieren und lieber auf eine Feature-Entwicklung zu setzen.

Die Gründe dafür sind schlichtweg die Zeit und die Kosten, die solch eine Aktion mit sich bringt. Jedoch birgt diese Entscheidung ein erhebliches Risiko: Kommt es zu einem Security-Incident, können die Folgekosten schnell deutlich höher ausfallen, als der Umstieg auf die nächsthöhere Version.

Was für Techniker zur Selbstverständlichkeit gehört, stößt auf Managementebene oft auf großes Unverständnis. In diesem Artikel gehe ich auf die Gründe ein, die hinter einem technischen Upgrade stecken, und gebe Einblick in praktische Tools, welche dies vereinfachen.

Inhalt

Wartungsende externer Bibliotheken: Risiken erkennen und rechtzeitig handeln
Tools in der Praxis
Gründe für technische Upgrades
Fazit

Wartungsende externer Bibliotheken: Risiken erkennen und rechtzeitig handeln

In der Entwicklung wird auf externe Bibliotheken gesetzt, welche regelmäßig neue Versionen veröffentlichen. Diese Versionen werden jedoch nicht dauerhaft gewartet, sondern nach einem bestimmten Zeitraum nicht mehr mit Bug-Fixes und Security-Updates versorgt. Sobald eine Version nicht mehr im Wartungsfenster liegt, ist Vorsicht geboten. Unternehmen sollten daher frühzeitig eine Strategie entwickeln, wie in diesem Fall vorzugehen ist.

Eine mögliche Strategie wäre es, die Aktualisierung aufzuschieben und diese als Technische Schuld aufzunehmen, um sich auf andere Themen zu konzentrieren. Dies erfolgt jedoch unter der Verpflichtung, die Technische Schuld zu einem späteren Zeitpunkt zu begleichen.

Weiters könnte ein kommerzieller Enterprise-Support erworben werden, welcher von gewissen externen Bibliotheken bzw. Drittanbietern angeboten wird, oder die Bibliotheken werden in den einzelnen Applikationen aktualisiert, wodurch weiterhin Bug-Fixes und Security-Updates eingespielt werden können.

Tools in der Praxis

Um sich ein besseres Bild über mögliche Schritte eines technischen Upgrades machen zu können, gehe ich nun auf ein konkretes Beispiel ein – eine Spring-Boot-Applikation mit Angular-Frontend. Dabei werden Tools eingesetzt, welche automatisiert oder zumindest teilautomatisiert Upgrades vollziehen können.

1. Spring-Boot Upgrade

Ab einer gewissen Anzahl von Applikationen ist es sinnvoll, Tools für das Upgrade zu verwenden. Das heißt, dass Entwickler dies nicht händisch, sondern mit Hilfe von bewährten Tools, automatisiert oder teilautomatisiert, durchführen können. Dies hat den Vorteil, dass als Resultat nur noch wenige und im besten Fall gar keine manuellen Schritte, die der Entwickler vornehmen muss, notwendig sind, damit die Applikation vollständig migriert ist. Zwei der effektivsten Tools für das Upgrade von Spring-Applikationen sind die folgenden:

Spring Application Advisor

Tanzu Spring – das Unternehmen hinter dem Spring-Ökosystem – bietet einen kommerziellen Enterprise-Support an. Dieser umfasst nicht nur eine verlängerte Wartung bestehender Spring-Versionen, sondern auch den Spring Application Advisor: ein Tool, welches automatisierte Upgrades von Spring-Boot-Anwendungen unterstützt und damit die Modernisierung deutlich vereinfacht [1] [2].

OpenRewrite

Da der Erwerb einer Enterprise-Lizenz mit hohen Kosten verbunden ist, hat sich in der Community eine Reihe von Open-Source-Projekten etabliert, die die Migration von Spring-Anwendungen erleichtern. Das bekannteste und leistungsfähigste davon ist OpenRewrite [3].

2. Angular Upgrade

Angular ermöglicht automatische Migrationen, allerdings jeweils nur zur unmittelbar nächsten Version. Dadurch muss dieser Schritt bei größeren Versionssprüngen mehrfach durchgeführt werden. Wer nicht auf die nächste Version beschränkt sein möchte, sollte sich hingegen Nx [4] genauer ansehen.
Nx ist eine Erweiterung der Angular-CLI und unterstützt unter anderem automatische Migrationen von Angular-Applikationen über mehrere Versionssprünge hinweg.

Es sei jedoch angemerkt, dass die automatische Migration sich auf Angular selbst beschränkt und hinzugefügte Dependencies nicht automatisch aktualisiert. Allerdings stellen größere Dependencies wie NgRx eigene Migrationsskripte bereit, die eine automatische Migration auch für diese Pakete ermöglichen.

Mit den neuesten Angular-Versionen wurden zusätzliche Konzepte eingeführt, die einerseits den Time to First Paint (TFP) – also den Zeitpunkt, zu dem das erste Pixel gerendert wird – und den First Contentful Paint (FCP) – den Moment, in dem erstmals sichtbarer Inhalt erscheint – deutlich verbessern. Andererseits ermöglichen sie durch den Einsatz von Signals eine erheblich gesteigerte Performance, da unnötige Re-Renderings reduziert werden.

Für einzelne neue Konzept werden eigene automatisierte Migrationsskripts von Angular bereitgestellt [5]. Dies übernimmt einen Großteil der notwendigen Anpassungen, jedoch müssen noch ein paar manuelle Schritte durchgeführt werden.

Um einen Einblick in den technischen Ablauf eines Migrationsprozesses zu erhalten, habe ich einen Blog-Post veröffentlicht. Dieser geht auch auf die Vorteile von Signals ein und erklärt welche Anwendungsgebiete es dafür gibt.

3. Renovate Bot

Um sicher zu gehen, dass alle Dependencies aktuell sind kann ein bewährtes Tool namens Renovate [6] verwendet werden. Dieses scannt alle Dependencies innerhalb einer Applikation und versucht die neueren Versionen zu übernehmen. Dieser kann so konfiguriert werden, dass Minor-Updates automatisch übernommen werden, ohne, dass Entwickler die Änderungen freigeben müssen. In einer gut konfigurierten CI/CD Pipeline würden diese Änderungen direkt deployt und E2E-Tests ausgeführt werden um auf die nächsthöhere Stage zu deployen. Der Renovate-Bot sollte ausschließlich an festgelegten Tagen und außerhalb der regulären Betriebszeiten durchgeführt werden, um unnötige Lasten zu vermeiden.

Gründe für technische Upgrades

Im vorigen Punkt wurde auf Strategien eingegangen, welche Unternehmen bei technischen Upgrades anwenden können. Nun wird näher auf das Aufschieben von Upgrades bzw. die Aufnahme als Technische Schuld eingegangen. Oftmals wird die Technische Schuld erst beglichen, wenn genug Budget für solch ein Vorhaben vorhanden ist.

Doch genau das kann dazu führen, dass eine kritische Sicherheitslücke (CVE) gravierende Folgen mit sich bringt: Entweder werden die Versionen zeitaufwendig aktualisiert, die betroffene Version manuell gepatcht oder kurzfristig eine kostenpflichtigen Enterprise-Lizenz erworben. In solchen Situationen ist Zeit ein entscheidender Faktor – und jedes Zögern kann teuer werden.

Dies führt dazu, dass eine immer größere Kluft zwischen der eingesetzten und der aktuellen noch gewarteten Version entsteht, wodurch sowohl die Kosten des Upgrades als auch das Risiko für Sicherheitslücken steigen. Zusätzlich wird dadurch eine schlechtere Performance, welche sich nicht nur während der Entwicklung, sondern auch in der Produktion bemerkbar macht, in Kauf genommen.

Im schlimmsten Fall wird ein Produkt-Upgrade so lange hinausgezögert, bis das zugrunde liegende Framework oder die Technologie selbst nicht mehr unterstützt wird. In solchen Fällen bleibt oft keine andere Möglichkeit, als die gesamte Applikation auf einen modernen Technologiestack zu migrieren – was die aufwendigste und kostenintensivste Form eines Upgrades darstellt. Der Grund dafür ist einfach: Eine automatisierte oder teilautomatisierte Migration ist dann meist nicht mehr möglich, weil es weder Toolunterstützung noch ausreichende Dokumentation gibt. Stattdessen muss ein großer Teil der Anwendung neu entwickelt werden.

Eine Anekdote aus der Praxis: Ich war bei einem Kundentermin, in dem es um die Modernisierung einer Rich-Client-Applikation ging. Auf meine Frage, warum dieses Upgrade jetzt und nicht bereits vor ein paar Jahren angestoßen wurde, antwortete man mir, dass die Entwickler, die sich mit dem alten Technologiestack und dem Code auskennen, bald in Pension gehen würden und dies deshalb jetzt erfolgen müsse.

Dies führt mich zum nächsten wichtigen Punkt. Die Wartbarkeit eines Produkts hängt sehr stark mit dem verwendeten Technologie-Stack zusammen. Neuere Technologie-Stacks sowie neuere Versionen von Bibliotheken können einfacher gewartet werden. Wenn die Umsetzung der Bug-Fixes und Feature-Requests in einer Applikationen wochenlang dauern, ist dies ein Anzeichen dafür, dass entweder Technische Schulden abgebaut werden müssen und/oder ein Upgrade sinnvoll wäre. Das heißt, dass die Wartbarkeit von Altsystemen einerseits aufgrund des fehlenden Know-Hows und andererseits durch den enormen Zeitaufwand, sich in alte Technologien einzulesen, in Mitleidenschaft gezogen wird.

Zusätzlich trägt der Einsatz von Alttechnologien nicht zur Entwicklerzufriedenheit bei. Veraltete Dokumentationen, lange Wartezeiten bei CI/CD-Pipelines sowie lange Build-Times führen einerseits zu Frustration unter den Entwicklern und andererseits dazu, den Fokus nicht auf die eigentliche Funktionalität zu legen, was schließlich eine der Hauptaufgaben eines Entwicklers wäre. Daraus resultierend dauert es länger, Features zu entwickeln.

Wer sowohl die Performance seiner Anwendung sichern als auch ein schnelleres Time-to-Market erreichen möchte, muss erkennen: Der Schlüssel zum Erfolg liegt in einem modernen Technologie-Stack kombiniert mit einer klar definierten Upgrade-Strategie.

Fazit

Technische Upgrades sind kein einmaliges Vorhaben, sondern ein kontinuierlicher Prozess, der frühzeitig in Unternehmen verankert werden sollte. Nur so lassen sich Migrationen effizient, automatisiert oder zumindest teilautomatisiert umsetzen. Je länger ein Upgrade hinausgezögert wird, desto höher steigen nicht nur die Kosten, sondern auch das Risiko sicherheitsrelevanter Schwachstellen, welche kritische Folgen mit sich bringen könnten. Mit Tools wie Renovate [7] lässt sich dieser Prozess gezielt unterstützen – einfach integrierbar und mit dem Ziel, Abhängigkeiten stets auf dem neuesten Stand zu halten. Darüber hinaus helfen Tools wie OpenRewrite [3] oder die von Angular bereitgestellten Migrationsskripts, den Migrationsprozess einfacher zu gestalten.

Planen Sie frühzeitig eine Upgrade-Strategie – sonst bleibt als letzter Ausweg nur die kostenintensive Neuentwicklung.