Spring Boot 2.7 end of life, for anyone not paying for commercial support, was June 30, 2023. That is the open-source support end date in spring.io's own project data. The last free release, 2.7.18, shipped on November 23, 2023, so a 2.7 app has gone almost three years without a free fix. Commercial support for 2.7 runs to June 30, 2029, which is why some teams feel no urgency. If you are not paying for it, you are running an unpatched framework.
You will see "November 2023" in a lot of older blog posts. That is when the final free patch shipped, not the official support date, which is June 30, 2023.
Key Takeaways
- Spring Boot 2.7 OSS support ended 2023-06-30; commercial support runs to 2029-06-30.
- As of October 2026, only Spring Boot 4.0 and 4.1 still have OSS support. 3.5 went commercial-only on 2026-06-30.
- The move to 3.x requires Java 17 and the javax to jakarta namespace change, which touches almost every file that imports a servlet, persistence or validation class.
- Go to 2.7's latest patch, then 3.x, then 4.x. Skipping steps is where these migrations stall.
Spring Boot 2.7 End of Life and Every Branch After It
From the spring.io generations data that powers the support page:
| Branch | Released | OSS support ends | Commercial support ends |
|---|---|---|---|
| 2.7.x | 2022-05-31 | 2023-06-30 | 2029-06-30 |
| 3.4.x | 2024-11-30 | 2025-12-31 | 2026-12-31 |
| 3.5.x | 2025-05-31 | 2026-06-30 | 2032-06-30 |
| 4.0.x | 2025-11-30 | 2026-12-31 | 2027-12-31 |
| 4.1.x | 2026-06-30 | 2027-07-31 | 2028-07-31 |
Read that table and one thing jumps out: open-source branches now live about a year. If you want free support, you are signing up to upgrade every year from here on. If you want a long runway, 3.5 with commercial support to 2032 is the branch built for that.
My default for a startup: target 4.1. You will be upgrading yearly anyway, and getting the jakarta pain behind you on the newest line means the next move is small.
What Breaks Going From 2.7 to 3.x
The official Spring Boot 3.0 Migration Guide is direct about the big items:
1. Java 17 minimum. "Spring Boot 3.0 requires Java 17 or later." If you are still on Java 11, that is its own project, covered in Java 11 end of life.
2. javax to jakarta. "Jakarta EE now uses jakarta packages rather than javax." Every `javax.servlet`, `javax.persistence` and `javax.validation` import changes. IDE tooling and OpenRewrite recipes do most of the mechanical work; the pain is in third-party libraries that have not moved.
3. Spring Security 6. The guide suggests upgrading to Security 5.8 while still on 2.7, because the configuration model changed. Teams with custom auth filters spend the most time here.
4. Hibernate 6.1. Query behavior and some type mappings change. Your integration tests are what save you.
5. Trailing slash matching is off by default. `/users/` no longer matches `/users`. This one breaks clients in production if nobody tests it.
The guide also says to upgrade to the latest 2.7.x before starting, and to add `spring-boot-properties-migrator` so renamed properties get reported at startup. Both are cheap and both catch problems early.
The 4.0 migration has its own wiki guide. Do the 3.x move first and ship it before you read that one.
A Concrete Version
A hypothetical marketplace backend: Spring Boot 2.7.18, Java 11, 95,000 lines, 14 groups of REST controllers, a custom JWT filter chain, Hibernate with about 120 entities, and a test suite at 62% line coverage.
Sizing the move to 3.5, then 4.1:
- Java 11 to 17 in place (dependency bumps, reflection fixes): 60 hours.
- javax to jakarta with an automated recipe, then manual fixes for 9 libraries that needed new major versions: 40 hours.
- Spring Security 5.8 step, then 6 (rewriting the filter chain config, retesting auth flows): 50 hours.
- Hibernate 6 query and mapping fixes across 120 entities, at an average of 20 minutes each with most needing nothing: 40 hours.
- Trailing slash audit and client contract tests: 12 hours.
- 3.5 to 4.1 after the 3.x release is stable: 40 hours.
- Staging soak, load test, rollout: 30 hours.
Total: 60 + 40 + 50 + 40 + 12 + 40 + 30 = 272 hours. Two senior engineers at about 35 productive hours a week each get there in about four weeks, plus a buffer week for the surprises a 62% coverage suite does not catch.
The Honest Counterpoint
Paying for commercial 2.7 support until 2029 is a legitimate choice for a product you plan to retire. If the app is in maintenance mode with a sunset date, spending 272 hours to modernize it is waste. Buy the support, freeze features, and put the hours into the replacement.
The other honest point: test coverage drives this estimate more than code size. At 30% coverage, I would double the Hibernate and Security lines and add a week of manual QA. If you do not know your coverage, find out before you commit to a date. And if the codebase is in bad enough shape that you are debating a rewrite, read rewrite or refactor first.
Who Should Do the Work
The engineers who built the 2.7 app know where the bodies are buried, but they are also the ones every product request lands on. Splitting the work helps: one internal engineer as reviewer and domain guide, one or two outside senior Spring engineers doing the migration full time. That is the setup I see finish on schedule. It is the same pattern as any legacy modernization hire.
When you interview for it, ask about a specific jakarta migration they shipped, and what broke. This hiring guide for Java developers covers the rest. Ruzora sends a vetted shortlist of senior backend engineers within 72 hours; see backend engineers here.
Frequently Asked Questions
When was Spring Boot 2.7 end of life?
Open-source support for Spring Boot 2.7 ended on June 30, 2023, per spring.io. Commercial support continues until June 30, 2029. The "November 2023" date in older posts is when the last free release, 2.7.18, shipped.
Should I migrate from Spring Boot 2.7 to 3.5 or 4.x?
For most startups, 4.1, which has OSS support to July 31, 2027. Choose 3.5 only if you will pay for commercial support, which runs to 2032. Either way, go through 3.x first so the jakarta and Security 6 changes land in one release.
How long does a Spring Boot 2 to 3 migration take?
For a mid-size service, three to six weeks with two senior engineers. Java version, Spring Security customization and test coverage drive the range far more than lines of code.
The Bottom Line
Spring Boot 2.7 end of life passed in 2023. Every month on it without commercial support is a month of unpatched CVEs. Pick 4.1, do the 3.x step first, and staff it so it actually finishes. If you need the people, request a shortlist.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
