Spring Boot 3.5 ohne Support: Was jetzt zu tun ist

Am 25. Juni 2026 ist Spring Boot 3.5.16 erschienen. Das Spring-Team schreibt dazu, es sei die letzte Open-Source-Version der 3.5-Generation, und empfiehlt, auf 4.0 oder 4.1 zu wechseln. Seit dem 30. Juni gibt es für 3.5 keine freien Patches mehr. Spring Framework 6.2, auf dem 3.5 aufbaut, ist im selben Monat aus dem freien Support gefallen.

Wer jetzt erst anfängt, sollte die nächsten Termine kennen, bevor er ein Ziel wählt.

Die Termine

Daraus folgt eine unbequeme Rechnung. Wer jetzt von 3.5 auf 4.0 wechselt, steht Ende Dezember 2026 wieder ohne freie Patches da. Das sinnvolle Ziel ist 4.1.

Die Daten stammen aus dem Release-Hinweis zu 3.5.16 auf spring.io und der Übersicht auf endoflife.date. Prüf sie vor einer Entscheidung noch einmal selbst, die Hersteller passen solche Termine gelegentlich an.

Was "keine freien Patches" praktisch bedeutet

Die Anwendung läuft morgen genauso wie heute. Es passiert nichts Sichtbares. Was sich ändert: Wird in Spring Boot 3.5 oder Spring Framework 6.2 eine neue Sicherheitslücke gefunden, bekommst du dafür keine freie Korrektur mehr. Du hast dann drei Wege: kommerziellen Support kaufen, einen Drittanbieter mit verlängertem Support beauftragen oder upgraden.

Seit dem 11. September 2026 kommt ein weiterer Punkt dazu. Ab diesem Tag gelten die Meldepflichten des Cyber Resilience Act. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden, und zwar auch für Produkte, die schon vor dem eigentlichen Stichtag des CRA im Dezember 2027 auf dem Markt waren. Reine SaaS-Angebote fallen nach meinem Verständnis grundsätzlich nicht darunter, solange sie nicht Teil eines Produkts sind. Ob und wie dein Produkt betroffen ist, lass rechtlich prüfen. Das hier ist keine Rechtsberatung.

Der Zusammenhang ist trotzdem klar: Eine Lücke, die du melden musst, aber mangels Patch nicht schließen kannst, ist die schlechteste Lage, in die man geraten kann.

Warum der Sprung in gewachsenen Systemen hängen bleibt

In einer jungen Codebasis ist ein Major-Upgrade Arbeit, aber planbar. In einem System, das zehn Jahre gewachsen ist, scheitert es selten an Spring selbst. Es scheitert an dem, was drumherum gewachsen ist:

• Bibliotheken, die auf alten Versionen festgenagelt sind. Irgendwann wurde eine Version fixiert, weil die neuere etwas kaputt gemacht hat. Warum, weiß heute niemand mehr.
• Eigene Forks und Patches. Eine angepasste Kopie einer Bibliothek, die seit Jahren nicht mehr mit dem Original abgeglichen wurde.
• APIs, die schon lange als veraltet markiert sind. Die Warnungen im Build hat man sich abgewöhnt zu lesen. Mit dem Major-Sprung werden sie zu Fehlern.
• Fehlende Tests an den richtigen Stellen. Ohne Tests an den Rändern eines Bereichs weiß niemand, ob er nach dem Upgrade noch dasselbe tut.
• Wissen, das nur eine Person hat. Den Teil, an dem das Upgrade hängt, versteht oft genau ein Mensch im Team. Mehr dazu im Leitfaden Wenn nur eine Person das System versteht.

Deshalb dauern solche Upgrades in der Praxis länger als geplant, und deshalb werden sie verschoben, bis der Support ausläuft.

So gehst du vor

1. Bestandsaufnahme vor der ersten Codezeile

Erstelle eine Liste aller direkten und transitiven Abhängigkeiten mit ihrer Version (mvn dependency:tree oder gradle dependencies). Markiere alles, was fest gepinnt, geforkt oder seit Jahren nicht aktualisiert ist. Diese Liste ist dein eigentlicher Projektplan.

2. Erst auf die letzte 3.5-Version, dann weiter

Zieh das System zuerst auf 3.5.16 und räum alle Warnungen zu veralteten APIs ab. Das ist der günstigste Teil der Arbeit und nimmt dem großen Sprung die Hälfte seines Schreckens. Die Hinweise des offiziellen Migrationsleitfadens zu 4.0 helfen bei der Reihenfolge.

3. Tests an die Ränder, nicht in die Mitte

Du brauchst keine vollständige Testabdeckung. Du brauchst Tests, die das Verhalten eines Bereichs von außen festhalten: Was geht rein, was kommt raus. Dann kannst du darunter umbauen, ohne dass sich dieses Verhalten unbemerkt ändert.

4. Was das Upgrade blockiert, zuerst herauslösen

Oft ist es ein einzelner Bereich, der mit einer alten Bibliothek verwachsen ist und das ganze Upgrade aufhält. Statt das ganze System auf einmal anzuheben, löst du diesen Bereich zuerst heraus und gibst ihm eine eigene Schnittstelle. Danach ist der Rest frei für das Upgrade. Wie du den richtigen Bereich findest, steht im Leitfaden Welchen Bereich du zuerst herauslöst.

5. Ziel 4.1, nicht 4.0

Wenn ihr ohnehin anfasst, geht direkt auf die Version mit dem längsten freien Support.

Und im Frontend: Vue 2 und AngularJS

Dasselbe Muster gibt es im Frontend, nur schon länger. Vue 2 bekommt seit dem 31. Dezember 2023 keinen Support mehr, AngularJS seit dem 31. Dezember 2021. Hier ist ein Upgrade in vielen Fällen eher eine Neuentwicklung der Oberfläche. Auch die muss nicht auf einmal passieren: Eine neue Oberfläche kann Seite für Seite neben der alten wachsen, bis die alte nicht mehr gebraucht wird.

Fazit

Die wichtigste Frage ist nicht, wann ihr upgradet, sondern woran es bei euch hängen würde. Geh einmal mit deinem Team durch, auf welcher Version euer Backend steht und welcher Teil des Systems ein Upgrade heute verhindern würde. Wenn die Antwort lautet "das wissen wir erst, wenn wir es versuchen", ist genau das der erste Schritt.

Willst du wissen, woran euer Upgrade hängen würde? Im kostenlosen Herauslöse-Check schauen wir uns das in 30 Minuten gemeinsam an.

👉 Herauslöse-Check buchen