Spring Boot 2.7 vor dem Support-Ende: Boot 4, Extended Support oder TypeScript-Neuaufbau?

Wenn Ihr Kernsystem auf Spring Boot 2.7 läuft, hat es seit November 2023 keinen einzigen Open-Source-Sicherheitspatch mehr gesehen — und am 31. Dezember 2026 fällt mit dem kommerziellen VMware-Tanzu-Support auch das letzte Sicherheitsnetz weg. Was viele IT-Verantwortliche seit über zwei Jahren vor sich herschieben, hat damit ein hartes Fälligkeitsdatum bekommen. Fünfeinhalb Monate reichen für eine geordnete Entscheidung. Sie reichen nicht mehr für eine geordnete Entscheidung plus ein komplettes Migrationsprojekt.

Deshalb dieser Artikel: kein Alarmismus, sondern ein nüchterner Entscheidungsbaum. Drei Wege stehen offen — die Migration auf Spring Boot 4, der Kauf von Extended Support oder der service-weise Neuaufbau im TypeScript-Stack. Jeder Weg ist für bestimmte Konstellationen der richtige. Welcher für Ihre, hängt an drei Kriterien: der Restlebensdauer der Anwendung, Ihrer Teamlage und dem Integrationsgrad des Systems.

Zur Erinnerung, wie es so weit kam: Der Open-Source-Support für Spring Boot 2.7 endete bereits im November 2023 mit dem letzten Courtesy-Patch 2.7.18. Seitdem existiert Boot 2.7 nur noch hinter der Bezahlschranke — VMware Tanzu hat den kommerziellen Support bis zum 31. Dezember 2026 verlängert. Danach bleiben ausschließlich Drittanbieter, die Patches für abgekündigte Versionen gegen Gebühr weiterpflegen.

Das allein wäre eine übersichtliche Deadline. Brisant wird die Lage durch das, was parallel passiert ist: Spring Boot kennt kein LTS-Modell. Jede Minor-Version erhält zwölf Monate Open-Source-Support, danach ist Schluss — 3.3 lief im Juni 2025 aus, 3.4 im Dezember 2025, und seit Ende Juni 2026 ist mit dem Support-Ende von 3.5 die gesamte 3.x-Linie ohne Open-Source-Patches. Stand heute wird nur noch die 4.x-Linie gepflegt. Wer 2023 diszipliniert auf Boot 3 migriert ist, steht also schon wieder vor einem Pflicht-Upgrade.

Das Muster dahinter ist der eigentliche Befund: Der Spring-Stack erzwingt strukturell einen permanenten Upgrade-Zyklus — oder Supportverträge. Zum Vergleich: Node.js 24 läuft als Active LTS bis Oktober 2026 und erhält danach Wartungs-Patches bis zum 30. April 2028, kostenlos und mit rund 30 Monaten Planbarkeit je LTS-Linie. Dieser Unterschied ist kein Feature-Argument, sondern ein Betriebskostenposten — wir haben ihn im Entscheider-Vergleich NestJS vs. Spring Boot ausführlich durchgerechnet.

Der Sprung von Boot 2.7 auf die 3.x- oder 4.x-Linie ist kein Versionswechsel, sondern ein Plattformwechsel: Spring Boot 3 setzt zwingend Java 17 oder neuer voraus, dazu kommt der Namespace-Umzug von javax auf jakarta — eine Änderung, die sich durch jede einzelne Abhängigkeit zieht. Für viele Bestandslandschaften bedeutet das zwei Modernisierungen in einem Projekt: erst die Runtime, dann das Framework. Laut New Relic 2024 liefen knapp 30 Prozent der Java-Produktionsanwendungen noch auf Java 8 — wer dort steht, hat den weitesten Weg vor sich.

Und die JDK-Frage öffnet eine zweite Akte: die Lizenz. Oracles Per-Employee-Modell setzt 15 US-Dollar pro Mitarbeiter und Monat an (bei Unternehmen unter 1.000 Mitarbeitern) — bezahlt wird die gesamte Belegschaft, nicht die tatsächlichen Java-Nutzer. Laut Gartner verteuert das die Java-Lizenzierung auf das Zwei- bis Fünffache der Altkosten. Als Beispielrechnung: Ein Mittelständler mit 500 Mitarbeitern läge bei rund 90.000 US-Dollar pro Jahr. OpenJDK-Distributionen sind die faire und funktionierende Alternative — aber auch dort tickt der Kalender: Der Oracle-Premier-Support für JDK 17 endet am 30. September 2026, der kostenlose Temurin-Community-Support für Java 8 im November 2026.

Dass das kein theoretisches Risiko ist, zeigt die Umfrage von Azul und ITAM Forum vom Juli 2025: 73 Prozent der Unternehmen wurden in den letzten drei Jahren von Oracle wegen Java auditiert, jedes vierte gibt über 500.000 US-Dollar pro Jahr für die Bereinigung von Lizenz-Non-Compliance aus. Die Boot-2.7-Frage ist deshalb in Wahrheit eine Stack-Frage — und genau darum lohnt es sich, alle drei Wege nebeneinanderzulegen, statt reflexhaft den Upgrade-Pfad zu buchen.

Der Standardweg, und für viele Systeme der richtige. Sie bleiben im vertrauten Ökosystem, das Spring-Know-how Ihres Teams bleibt voll verwertbar, und die Migration ist ein gut dokumentierter Pfad. Ehrlich budgetieren muss man zwei Dinge: das Pflichtpaket aus Java 17+ und jakarta-Umstellung — und die Tatsache, dass Sie nach der Migration wieder im Zwölf-Monats-Fenster stehen. Das nächste Pflicht-Upgrade ist strukturell eingebaut. Weg A ist kein Einmalprojekt, sondern der Eintritt in einen Dauerzyklus, den man als wiederkehrenden Posten in der Betriebskostenplanung führen sollte.

Der Zeitkauf. Bis Ende 2026 trägt der Tanzu-Vertrag, danach übernehmen Drittanbieter wie HeroDevs die Patch-Versorgung abgekündigter Versionen. Das ist ein legitimer Weg — für Anwendungen mit definiertem Ablaufdatum. Wenn ein System in zwei Jahren ohnehin abgelöst wird, ist bezahlter Stillstand billiger als jede Migration. Man sollte sich nur nichts vormachen: Extended Support kauft Zeit, keine Zukunft. Die Migration wird später nicht billiger, das Team arbeitet weiter auf einem Stack von gestern, und die Personalseite rechnet mit: Senior-Java-Entwickler kosten laut Robert Half 75.000 bis 95.000 Euro im Jahr — und für Expertise auf Alt-Versionen wird der Markt eher enger als weiter.

Der Weg, den kaum ein Spring-Migrationsleitfaden erwähnt — aus naheliegenden Gründen. Wenn ein Pflicht-Upgrade ohnehin jede Abhängigkeit anfasst, ist das der natürliche Moment für die Grundsatzfrage, ob jeder Service auf der JVM weiterleben muss. Gemeint ist kein Big-Bang-Rewrite, sondern der schrittweise Neuaufbau einzelner Services per Strangler-Pattern: Neue TypeScript-Services in NestJS docken per API-Vertrag an das Bestandssystem an und übernehmen sukzessive Verantwortung. NestJS bringt dabei die aus Spring vertrauten Konzepte mit — Dependency Injection, Module, Guards — und ist mit rund drei Millionen wöchentlichen npm-Downloads und Produktiveinsatz bei Adidas, Autodesk und Decathlon kein Nischen-Experiment. Für die neu gebauten Services entfällt die JDK-Lizenzfrage vollständig; die Runtime-Basis Node 24 LTS ist bis 2028 kostenlos abgesichert. Wie die Koexistenz mit dem Java-Kernsystem in der Praxis funktioniert — API-Verträge, Team-Schnitt, Datenhoheit —, haben wir im Artikel zur Two-Speed IT neben dem Java-Kernsystem beschrieben.

Erstens: die Restlebensdauer der Anwendung. Wird das System in fünf Jahren noch aktiv weiterentwickelt? Dann scheidet Weg B aus — bezahlter Stillstand ist für lebende Systeme die teuerste Option, weil er die Entscheidung nur vertagt und verteuert. Für Systeme mit beschlossenem Ablösedatum gilt das Gegenteil: Dort ist Extended Support der ehrlichste Weg, und jede Migration wäre verbranntes Budget.

Zweitens: die Teamlage. Ein eingespieltes Spring-Team mit gesicherter Nachbesetzung macht Weg A günstig und risikoarm. Wer dagegen ohnehin Mühe hat, Java-Positionen zu besetzen, sollte den Talentmarkt in die Rechnung nehmen: Laut Stack Overflow Developer Survey 2025 nutzen 48,8 Prozent der professionellen Entwickler TypeScript, Java liegt bei 29,6 Prozent. Der Umstieg von Java auf TypeScript ist dabei machbarer, als viele erwarten — gerade weil NestJS die Spring-Architekturmuster übernimmt, ist er für ein Java-Team kein Kulturbruch, sondern ein Sprachwechsel bei vertrauter Architektur.

Drittens: der Integrationsgrad. Ein monolithisches System mit Dutzenden tief verwachsenen Schnittstellen lässt sich nicht sinnvoll service-weise herauslösen — hier führt der Weg über A oder B. Eine Landschaft mit halbwegs sauberen Service-Grenzen und API-Verträgen ist dagegen der Idealfall für Weg C: Man beginnt mit dem Service, der den höchsten Änderungsdruck hat, und lässt den Rest in Ruhe weiterlaufen.

Eine Grenze ziehen wir dabei bewusst selbst: Für CPU-intensive Workloads — Batch-Verarbeitung, rechenintensive Datenjobs, Massiv-Parallelität — bleibt die JVM die stärkere Plattform; unabhängige Benchmarks zeigen dort 30 bis 68 Prozent Vorsprung gegenüber Node.js. Solche Services gehören nicht nach TypeScript verschoben, nur weil eine Deadline drückt. Die Domäne von Node und NestJS sind I/O-lastige API- und Web-Services. Meine Erfahrung aus Architektur-Reviews: Genau diese Services machen in den meisten Boot-2.7-Landschaften den Großteil aus — und fast keine Landschaft ist ein Entweder-oder. Der realistische Zielzustand ist fast immer eine bewusste Koexistenz — Weg A oder B für den Kern, Weg C für alles, was sich schnell weiterentwickeln muss.

Der konkrete nächste Schritt ist kein Migrationsprojekt, sondern ein Inventar. Listen Sie jeden Service auf Boot 2.7 — und ehrlicherweise auch die auf 3.x — mit drei Angaben: erwartete Restlebensdauer, Änderungsfrequenz der letzten zwölf Monate, Zahl und Tiefe der Schnittstellen. Ordnen Sie dann jedem Service einen der drei Wege zu — pro Service, nicht pauschal für die Landschaft. Wer im vierten Quartal sein Budget für 2027 plant, braucht diese Zuordnung vorher; sonst entscheidet nicht die Architektur über den Weg, sondern der Kalender.

Wenn Sie die Drei-Wege-Frage für Ihre Landschaft konkret durchspielen wollen: Als TypeScript-Agentur bauen wir Weg C — den service-weisen Neuaufbau in NestJS und Next.js — selbst, und genau deshalb sagen wir Ihnen in einem 30-minütigen Erstgespräch auch offen, wenn für Ihr System Weg A oder B der bessere ist. Eine Deadline ist ein schlechter Architekt — ein Inventar mit klaren Kriterien ist der bessere.

Stand: Juli 2026. Support- und Versionsdaten nach endoflife.date, spring.io und der Oracle-Support-Roadmap; Lizenzpreise sind US-Listenpreise, Gehaltsspannen nach Robert Half, Beispielrechnungen als solche gekennzeichnet.