EOL ist ein Datum, kein Vorschlag

Am 30. Juni 2026 endet der OSS-Support für Spring Boot 3.5. Ab dem 1. Juli gibt es aus der Community keine Bugfixes und keine Sicherheits-Patches mehr für diese Linie. Wer weiterläuft, läuft auf eigenes Risiko. Und genau hier fängt das Missverständnis an. Eine End-of-Life-Version verändert ihr Verhalten am Stichtag nicht. Sie startet am 1. Juli genauso schnell, antwortet genauso zuverlässig und besteht dieselben Tests wie am Tag davor. Das ist das Tückische daran. Es gibt kein Warnlicht, keinen Performance-Einbruch, keinen Absturz, der zur Migration zwingt. Alles fühlt sich stabil an. Und „stabil“ ist exakt das Wort, mit dem sich der Aufschub rechtfertigen lässt. Was sich ändert, ist unsichtbar. Sicherheitslücken werden nicht weniger, nur weil eine Version aus dem Support fällt, eher im Gegenteil. Neue CVEs werden weiter gefunden, auch in transitiven Abhängigkeiten. Der Unterschied: Für eine gepflegte Linie kommt ein Fix, für eine EOL-Linie nicht. Die Lücke bleibt offen. Aus einer Abhängigkeit, die „einfach läuft“, wird eine, die niemand mehr anfasst und über die niemand mehr nachdenkt bis ein Security-Scanner sie rot markiert oder, schlimmer, jemand anderes sie zuerst findet. Der eigentliche Punkt ist keine technische, sondern eine ehrliche Frage der Buchführung. Migrieren kostet Zeit, Tests und Nerven. Das ist real und lässt sich planen. Nicht migrieren kostet auch. Nur trägt diese Kosten niemand sichtbar im Budget, und sie fallen zu einem Zeitpunkt an, den man sich nicht aussuchen kann. „Wir machen das später“ heißt übersetzt: Wir behalten das Risiko, ohne es einzupreisen. EOL ist deshalb kein Vorschlag, über den man verhandeln kann, sondern ein Datum, das im Kalender steht. Man muss nicht am 1. Juli umgestiegen sein. Aber man sollte an dem Tag eine bewusste Entscheidung getroffen haben und nicht erst dann merken, dass man sie längst getroffen hat, indem man nichts tat.