Spring Boot 2 end of life came for open-source users on 30 June 2023, when Spring Boot 2.7, the last 2.x line, left OSS support. Spring's commercial support for 2.7 runs to 30 June 2029. Moving off 2.x isn't a version bump: Spring Boot 3 needs Java 17, the jakarta namespace and Spring Security 6.
The second surprise is that upgrading to 3 in 2023 didn't settle it. As of today, the only lines with open-source support are 4.0 and 4.1. This post lists every line's dates, explains what really changes when you leave 2.x, and sets out the order to do it in.
- Spring Boot 2.7, the last 2.x line, left open-source support on 30 June 2023. Spring's commercial support for 2.7 runs to 30 June 2029.
- Every 3.x line is now out of open-source support too. Spring Boot 3.5 left it on 30 June 2026.
- Leaving 2.x means Java 17, the javax to jakarta rename and Spring Security 6 at once, plus everything that touches them.
- Spring ships a new version every six months, so upgrades need to become routine work, not a project every few years.
When is Spring Boot 2 end of life?
For open-source users, it already happened. Spring's support table shows every 2.x line out of OSS support, with 2.7 the last to go, on 30 June 2023.
Commercial support is the exception. Spring lists commercial support for 2.7 to 30 June 2029, and for Spring Framework 5.3, the framework under Spring Boot 2.7, also to 30 June 2029. Spring Framework 5.3 left open-source support on 31 August 2024. If you need more time, that commercial contract is the bridge; it doesn't change the work at the far end.
Spring Boot EOL dates, line by line
| Spring Boot line | First released | Open-source support ends | Commercial support ends |
|---|---|---|---|
| 2.7.x | May 2022 | 30 June 2023 | 30 June 2029 |
| 3.0.x | November 2022 | 31 December 2023 | 31 December 2024 |
| 3.1.x | May 2023 | 30 June 2024 | 30 June 2025 |
| 3.2.x | November 2023 | 31 December 2024 | 31 December 2025 |
| 3.3.x | May 2024 | 30 June 2025 | 30 June 2026 |
| 3.4.x | November 2024 | 31 December 2025 | 31 December 2026 |
| 3.5.x | May 2025 | 30 June 2026 | 30 June 2032 |
| 4.0.x | November 2025 | 31 December 2026 | 31 December 2027 |
| 4.1.x | June 2026 | 31 July 2027 | 31 July 2028 |
Checked 27 October 2026 against Spring's Spring Boot support table. The current release on spring.io is 4.1.2, and Spring's table already lists a 4.2.x line, due in November 2026.
Two lines stand out. Spring Boot 3.4 (including 3.4.2 and every other 3.4 patch) left open-source support on 31 December 2025, and its commercial support ends on 31 December 2026. And 3.5, the last 3.x line, has a long commercial tail like 2.7, to 30 June 2032.
Spring's supported versions policy explains the pattern: "Spring Boot releases a new major or minor version every six months (in May and November)." It adds: "Minor versions will be supported for at least 12 months."
Why leaving Spring Boot 2.x isn't a version bump
Spring's Spring Boot 3.0 Migration Guide is long because three big changes arrive together, and each reaches past your own code into every library you use.
| Change | What it touches | What you'll notice |
|---|---|---|
| Java 17 baseline: "Spring Boot 3.0 requires Java 17 or later" | The JDK, build plugins and every library that must run on 17 | Builds fail on the old JDK; code that used JDK internals breaks on 17 |
Jakarta EE: "Jakarta EE now uses jakarta packages rather than javax" | Every servlet, persistence and validation import, and every library still built on javax | Compile errors across the codebase until each import and dependency moves |
| Spring Security 6.0 | Every security configuration class | Security config stops compiling, and authorization now applies to every dispatch type |
| Trailing slash matching off by default | URL routing | Spring's example: "GET /some/greeting/" no longer matches and returns a 404 |
| Renamed configuration properties | application.properties and YAML files | Old keys need renaming; Spring's spring-boot-properties-migrator module helps |
The Java change is a migration in its own right; our Java 8 to 17 migration guide covers it, and Java end of life dates by vendor shows how long each Java build is patched.
The Spring Security change catches teams that copied a configuration years ago. Spring's Spring Security 6.0 announcement says the release "comes with several breaking changes, like the removal of WebSecurityConfigurerAdapter." Spring's recommended replacement, since Spring Security 5.7, is "registering a SecurityFilterChain bean." The Spring Security 5.8 migration notes say antMatchers, mvcMatchers and regexMatchers give way to requestMatchers: "The deprecated methods are removed in Spring Security 6."
None of this is hard in a small, well-tested service. In a large one, the risk is everything that touches these areas: custom filters, error pages that are now behind authorization, libraries with no jakarta version, and URL clients that relied on a trailing slash.
How to get off Spring Boot 2.x, in order
- Get to the latest 2.7.x first. Spring's guide: "Before you start the upgrade, make sure to upgrade to the latest available
2.7.xversion." - Move 2.7 to Java 17. The 2.7 docs say Spring Boot 2.7.18 "is compatible up to and including Java 21," so you can separate the Java move from the framework move.
- Move Spring Security to 5.8. Spring recommends it: "It is recommended that you first upgrade to 5.8."
- Upgrade to Spring Boot 3.5. Add the
spring-boot-properties-migratormodule while you move renamed properties; Spring says to remove it once you're done. Spring's guide lists OpenRewrite recipes, the Spring Boot Migrator and IntelliJ IDEA support for the jakarta rename. - Then move to 4.x. The Spring Boot 4.0 release notes say: "we strongly recommend that you upgrade to Spring Boot 3.5" before going further. Spring Boot 4.1.2 still requires at least Java 17 and works up to Java 27.
Old Spring Boot 2 services are common legacy system examples, and each month on an unpatched line adds to the risks of running end-of-life software.
What we look at before the upgrade starts
The version table tells you when. It can't tell you how big the job is, because that depends on what each service touches. The 30-day assessment is fixed in scope, at a price agreed before we start. Over 30 days we read the codebase and the architecture around it, map how the services fit together and which libraries and integrations each one depends on, find the hidden architectural debt, and flag the security and compliance gaps, including every dependency past its support date and every security configuration that won't survive Spring Security 6.
The report says in plain language what is broken and what it would take to fix it, service by service. Your own team can do the upgrade from it, or we can do the work as a separate project with its own scope and price. Either way, the report stands on its own.
Email Santosh a short list of the services still on Spring Boot 2.x and the Java version each one runs.