Spring Boot migration risk analyzer: 2.x and 3.x to 4.x

An example, not your result. The input is a plausible composite rather than anyone's real project.

Spring Boot 2.7 stopped receiving open-source security patches on 2023-06-30. New vulnerabilities in that branch are not fixed unless you hold a commercial agreement.

The bar is the score. The bracket under it is the range that score could still land in, so a wide bracket means the row was estimated, not measured.

Top blockers

Most severe first.

Suggested sequence

In order. Nothing below starts until the phase above it has shipped.

1. 1. Prove the ground

   Remove the unknowns that change the plan before anyone writes migration code.

   • Resolve the blockers listed above first. Each one can invalidate the rest of the plan.
   • Confirm the exact deployment target and its Jakarta EE level. For a WAR this decides whether the upgrade is an engineering task or a procurement one.
   • Run the build on the target JDK with no other changes and record what breaks in the toolchain.
   • Inventory internal shared libraries and find out who owns each one and whether its build still works.
   • Write enough integration coverage on authentication, one write path and one paginated read to catch the silent failures later.

2. 2. JDK upgrade

   Move from Java 8 to 17 or later on the current Spring Boot version, and ship it.

   • Upgrade the build plugins, Lombok, JaCoCo and any bytecode agents first. They break before the application does.
   • Remove or replace PowerMock and anything else built on old cglib or ASM.
   • Deploy this on its own. Shipping the JDK change separately from the framework change is what makes a rollback meaningful.

3. 3. Namespace and framework

   Cross to Spring Boot 3.0 on the Jakarta namespace.

   • Run the OpenRewrite Spring Boot 3 recipes for the mechanical rename, then handle what they cannot: string-typed javax names in persistence.xml, web.xml, XML namespace URIs, taglib URIs and META-INF/services.
   • Replace anything with no Jakarta path rather than trying to upgrade it.
   • Rewrite security configuration to SecurityFilterChain beans and check the SecurityContext is saved explicitly in any custom filter.
   • Work through the Hibernate 6 type system, identifier generation and HQL changes against a copy of production data.

4. 4. Walk the 3.x line

   Move up through the 3.x minors to 3.5.

   • This is not free. 3.1 brings the Spring Security 6.1 request-matcher ambiguity, 3.2 changes path matching, 3.3 ships Flyway 10 and its per-database module split.
   • Take one minor at a time and run the integration suite between each.

5. 5. Spring Boot 4

   Land on 4.1, which is the current supported branch.

   • The cost here is Jackson 2 to Jackson 3 across every custom serializer, mixin and module, plus Spring Security 6 to 7.
   • Jakarta EE 11 API levels need Tomcat 11 or later, or Jetty 12.1 or later.
   • The Spring Boot module split means some imports move between finer-grained jars.

6. 6. Cutover

   Get it into production without discovering the silent failures from user reports.

   • Use a canary or a staged rollout. The failures in this upgrade appear under real traffic, not in a smoke test.
   • Watch authentication success rate, 403 rates on internal dispatches, and identifier collisions on any table with a Hibernate-generated id.
   • Remember-me cookies are invalidated by the hashing change, so expect a login spike at cutover.

Your own build file will score differently. Run it against the analyzer above and you get this same breakdown for your codebase, parsed in your browser with nothing uploaded.