März 2024. Ein Kollege von Rocksoft und ich steigen in ein Projekt ein — eine solide Anwendung, die seit Jahren läuft. Es stellt sich schnell heraus, dass sie auf Vue 2 aufgebaut ist, dessen End-of-Life am 31. Dezember 2023 war, ein Quartal zuvor. Das Framework wird offiziell nicht mehr gewartet: Es erhält keine Sicherheits-Patches mehr. Und dennoch lässt es sich noch installieren, der Build läuft durch, „es funktioniert." Jetzt ist 2026 — und das Projekt läuft immer noch auf Vue 2.
Das ist der Kern des Problems: „Es funktioniert" ist ein vorübergehender Zustand. Wir nehmen technische Schulden auf im Austausch für einen kurzfristigen Gewinn — ein schnelleres Release, ein weiteres Feature. Aber sie tragen Zinsen, und diese Zinsen wachsen mit jedem Monat der Verzögerung. Dieser Artikel handelt davon, was dieses Risiko wirklich bedeutet — und wie KI die Wirtschaftlichkeit des Abzahlens verändert.
Was es kostet
Schulden sind keine Budgetposition, die jemand bewusst genehmigt. Es ist die Lücke zwischen dem, was ein System warten sollte kosten, und dem, was es tatsächlich kostet.
Das Ausmaß ist real: Entwickler im durchschnittlichen Unternehmen verbringen etwa ein Drittel ihrer Zeit damit, Schulden abzubauen, anstatt neue Funktionen zu entwickeln. Bei einem zehnköpfigen Team entspricht das mehr als drei Vollzeitstellen pro Jahr — verbraucht durch unsichtbaren Overhead.
Warum Unternehmen es aufschieben — und warum das ein Fehler ist
Ein neues Feature hat ein Gesicht: Man kann es einem Kunden zeigen. Die Migration auf eine neuere Framework-Version hat keines. Wenn sie abgeschlossen ist, funktioniert die Anwendung genauso wie zuvor — nur hat sie Wochen Arbeit gekostet. Das Aufschieben erscheint daher rational, ist aber auf zwei Ebenen falsch.
Erstens bedeutet „nicht anfassen" nicht „es passiert nichts." Nicht gewartete Abhängigkeiten häufen neue Schwachstellen an, die niemand patcht, Browser stellen APIs ein, und die Dokumentation sowie Antworten online beziehen sich auf Versionen, die zwei Generationen neuer sind. Einen toten Stack zu warten ist wie Programmieren mit einer Taschenlampe in einem Archiv.
Zweitens vergrößert das Aufschieben die Schulden selbst. Jedes Feature, das auf einem veralteten Fundament hinzugefügt wird, ist neuer Code, der später neu geschrieben werden muss. Das Migrationsziel wartet nicht — es wächst mit jedem Sprint.
Und am Ende wartet ein Paradox: Das vernachlässigte Fundament beginnt, genau die Features zu blockieren, deretwegen es vernachlässigt wurde. In unserem Projekt waren die Bibliotheken, die benötigt wurden, um eines der Features zu erweitern, nur für die neuere Framework-Version verfügbar. Solange wir auf Vue 2 blieben, war dieses Feature unerreichbar.
Zwei Gesichter des Risikos
Wenn die Schulden zu groß werden, kann die Rechnung auf einmal ankommen — und sie schmerzt.
Equifax (2017): Angreifer drangen durch eine bekannte Schwachstelle in Apache Struts ein, für die seit Monaten ein Patch existiert hatte, der aber nie eingespielt wurde. Etwa 147 Millionen Datensätze mit personenbezogenen Daten wurden geleakt. Das ist der klassische Preis des Nicht-Aktualisierens — und wenig hat sich seitdem geändert, da fast alle Struts-Downloads noch immer auf nicht unterstützte Versionen gehen.
The axios-Angriff (2026) zeigt die andere Seite: „alles aktuell halten" ist auch kein Freifahrtschein für Sicherheit. Bei einem supply-chain-Angriff übernahmen Angreifer das Maintainer-Konto einer der beliebtesten JavaScript-Bibliotheken und veröffentlichten bösartige Releases, die bei der Installation einen Remote-Access-Trojaner herunterluden. Was hier versagte, war nicht Untätigkeit, sondern Automatisierung. Pull Requests von Dependency-Update-Bots genießen implizites Vertrauen und werden tendenziell ohne genaue Prüfung durchgewunken — und die bösartige Änderung verbreitete sich innerhalb von Minuten über öffentliche Repositories.
Die Lehre aus beiden Fällen: Updates erfordern Aufmerksamkeit, nicht nur Häufigkeit. Das Risiko liegt ebenso im Stillstand wie im blinden Vorwärtsstürmen.
End-of-Life bedeutet nicht nur fehlende Features
End-of-Support bedeutet vor allem: keine Sicherheits-Patches mehr. Und nicht nur für den Framework-Kern, sondern für das gesamte Plugin-Ökosystem darum herum, das mit ihm stirbt. Jede solche Abhängigkeit ist ein separates, nicht gewartetes Stück Angriffsfläche.
Dann kommt Compliance: Viele Teams können keine nicht unterstützte Software ausliefern aufgrund von Klauseln in SLAs und Verträgen — und „es funktioniert, also lassen wir es" kann irgendwann mit einem Audit kollidieren.
Kostenpflichtiger erweiterter Support ist manchmal verfügbar, aber er ist eine Krücke. Er kauft nur Zeit für das Unvermeidliche: die Migration.
Wie KI die Rechnung verändert
Das Hauptargument für das Aufschieben — „Migration kostet Wochen, die wir nicht haben" — ist gerade aufgehört, wahr zu sein.
Klassische Bots (Dependabot, Renovate) erkennen veraltete Pakete und öffnen PRs, aber sie beheben keine Breaking Changes. Bei größeren API-Änderungen hinterlassen sie dir einen roten Build, den du von Hand lösen musst. Language Models (Claude, Codex) gehen einen Schritt weiter: Sie führen die tatsächliche Transformation des Codes auf die neue Framework-Version durch. McKinsey schätzt, dass generative KI in der Anwendungsmodernisierung Zeitpläne um 40 bis 50 % beschleunigt und schuldenbedingte Kosten um etwa 40 % senkt.
Der Schlüssel ist der Verifikations-Loop, der die Lücke zwischen „der Code kompiliert" und „der Code funktioniert im Browser" schließt. Indem das Modell über MCP (z. B. Playwright- oder Chrome-Server) mit einem Browser verbunden wird, liest das Modell nach dem Neuschreiben einer View die Konsole selbst, erkennt Laufzeitfehler und Warnungen und behebt den Code, bevor ein Mensch ihn jemals sieht.
Ein Gegenargument ist notwendig: KI ist kein Autopilot. Modelle können Abhängigkeiten „halluzinieren" — manchmal mit Namen, die böswillig registriert wurden — und maschinell generierter Code fällt in dieselbe implizite Vertrauensfalle wie Bot-PRs. Es gibt davon viel, es sieht solide aus, und es ist verlockend, es ohne Review durchzuwunken. KI senkt die Kosten für die Durchführung der Migration — nicht die Kosten für das Verstehen, was in das Projekt einfließt. Der Mensch, der Code-Review macht, bleibt das wichtigste Element — besonders angesichts des Supply-Chain-Risikos.
In der Praxis
Beginne mit Sichtbarkeit: ein Audit deiner Abhängigkeiten und eine vollständige Liste dessen, was tatsächlich in das Projekt einfließt (ein SBOM) — inklusive transitiver Abhängigkeiten.
Halte Automatisierung an der Leine. Bot-PRs kommen unter menschliche Augen, eine Abkühlphase für frische Releases, Automerge höchstens für kleine Patches mit Testabdeckung. Behandle KI als beaufsichtigten Migrations-Beschleuniger, nicht als unbeaufsichtigten Ausführer.
Der schwierigste Teil ist meistens das Gespräch mit dem Business — und hier verliert der Engineer in der Regel, weil er über „Updates" spricht, wenn er über Risiko und Kosten sprechen sollte: ein Framework ohne Sicherheits-Patches, Vertragsklauseln, ein Drittel der Team-Zeit verloren durch Schulden.
Und da die Kosten der Migration selbst gerade gesunken sind, muss das alte „Wir können es uns nicht leisten" von Grund auf neu berechnet werden.
Technische Schulden verschwinden nicht von selbst. Aber mit den richtigen Tools kannst du endlich aufhören, nur die Zinsen zu zahlen — und anfangen, die Hauptschuld abzuzahlen, bevor sie über das hinauswächst, was du bewältigen kannst.
