Spring Boot 4 and Java 25: an upgrade path for integration services

Spring Boot 3.5 left open-source support on 30 June 2026. An integration service moves to Spring Boot 4.1 in separate steps: the last 3.5 patch, Spring Framework 7 with Jakarta EE 11 and Jackson 3, then Java 21 or 25 LTS, each proven by tests. Services still on Spring Boot 2 first move from javax to jakarta.

Spring publishes the support dates on the Spring Boot project page. These are the ones that shape the plan.

• 20 November 2025: Spring Boot 4.0.0 became generally available.
• 10 June 2026: Spring Boot 4.1.0 was released, followed by 4.1.1 on 20 August 2026.
• 30 June 2026: Spring Boot 3.5 left open-source support. Its last open-source release, 3.5.16, came out on 25 June 2026. Commercial support for 3.5 runs to 30 June 2032.
• 31 December 2026: Spring Boot 4.0 leaves open-source support.

Two conclusions follow. Target Spring Boot 4.1, not 4.0, because open-source support for 4.0 ends on 31 December 2026. And plan the Java version at the same time, because Spring Boot 4 needs Java 17 or later.

Staying on Spring Boot 3.5 breaks nothing when open-source support ends, and your services keep running. The end of open-source support is not a legal deadline: what ends is the stream of free releases, security fixes included. What remains is commercial support to 30 June 2032, or your own risk for every flaw found after 30 June 2026.

For an integration service, that risk sits in the parts that face other systems: the HTTP stack, the JSON mapping and the clients for messaging and databases. Those are the parts most exposed when a flaw is published.

The change from javax to jakarta came with Spring Boot 3. A service on Spring Boot 3.5 already uses the jakarta namespace, so the move to Spring Boot 4 is a different change: Spring Framework 7, Jakarta EE 11 with Jakarta Servlet 6.1, and Jackson 3, on Java 17 or later.

Services still on Spring Boot 2 have two moves to make. The first is the namespace: every import of the Java EE APIs, such as servlet, persistence and validation, changes from javax to jakarta, in your code and in every library you depend on. The second is the move to Spring Boot 4. Both can happen in one project, but keep them in separate steps, so that a failing test has one cause.

Move every service to 3.5.16, the last open-source release of Spring Boot 3.5, before you touch Spring Boot 4. Then work through the deprecation warnings the build reports. Deprecated code is where a major version removes things, and each warning you clear on 3.5 is one compile error fewer on 4.

Bring the tests to a state you trust before the upgrade starts. For an integration service, that means contract tests for each interface it offers or calls, not only unit tests. Update the build plugins and test libraries in the same step, to versions that work with both Spring Boot 3.5 and 4.

For a Maven build that inherits from the Spring Boot parent, the change itself is one line:

 <parent>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-parent</artifactId>
-  <version>3.5.16</version>
+  <version>4.1.1</version>
 </parent>

The work lies in what moves with that line:

• Spring Framework 7. Your code compiles against a new major version of the framework, and removed APIs show up as compile errors.
• Jakarta EE 11 and Jakarta Servlet 6.1. The servlet container and every Jakarta library you pin must match these versions.
• Jackson 3. JSON mapping is the core of most integration services. Jackson 3 is a new major version, so custom serialisers, modules and mapper settings need checking, and every payload needs a test.
• Third-party libraries. Each library needs a release that supports Spring Framework 7 and Jakarta EE 11. The libraries without one decide the date you can move.

Automated recipes, for example with OpenRewrite, do the mechanical part: version bumps, renamed properties and changed imports. They do not prove that a payload still maps as before. Only tests do that.

Spring Boot 4 runs on Java 17 or later. For a new baseline, choose a long-term support (LTS) release: Java 21 or Java 25. JDK 25 was released on 16 September 2025 as an LTS release. JDK 27, released on 15 September 2026, is not an LTS release.

Choose Java 25 if your libraries, monitoring agents and build tools support it. Choose Java 21 if one of them does not. Move the JDK in its own step and run the same tests again, so that a change in behaviour points to one cause.

An integration service on Spring Boot is judged by its payloads, not by its build. Before each step reaches production, run:

• contract tests for every API the service offers and every API it calls;
• serialisation tests that compare the JSON before and after the change, field by field, dates and empty values included;
• a run against the real message broker, database and identity provider in a test environment;
• a check of start-up and shutdown on the platform you deploy to.

Compare the metrics and traces of each service before and after every step. If the service exports traces with OpenTelemetry, a change in latency or error rate on one interface shows up there before a user reports it.

Release one service at a time where the interfaces allow it. Keep the previous version deployable until the new one has run in production for a period you agree in advance.

Spring Boot services that act as Camunda job workers, or as adapters next to IBM webMethods, follow the same four steps. Check that each client library they use, the Camunda client included, has a release for Spring Boot 4 before you set the date. If one of your services only maps and forwards messages, move it first: its tests are short, and it proves the plan on a small scale.

The dates in this article were checked on 17 October 2026 against spring.io and openjdk.org. How we plan and carry out the move is on the page Spring Boot 3.5 to 4 upgrade.