Spring Boot 3.5 Is Out of Free Support and 4.0 Follows in December: A Java Upgrade Plan That Lands on the Right Version

What Ended in June, and What Ends in December?

Spring's support model is predictable, which is exactly why it catches teams out. Each Spring Boot minor line gets roughly a year of free, open-source patches, followed by a longer window of paid commercial support. On 25 June 2026 the Spring team published Spring Boot 3.5.16 and stated plainly that it is the last OSS release of the 3.5.x generation, recommending that users upgrade to 4.0.x or 4.1.x. Spring Boot 3.5 was the final 3.x line, so for any team still on Boot 3, there is no newer free 3.x release to move to.

The underlying framework followed the same calendar. According to endoflife.date's Spring Framework tracker, open-source support for Spring Framework 6.2 ended on 30 June 2026, and the older 6.1 and 6.0 lines were already out of free support. Commercial support for 6.x runs until 2032, but that support is sold through VMware Tanzu, not published to Maven Central.

The deadline most teams have not noticed is the next one. Spring Boot 4.0, released in November 2025, has open-source support only until 31 December 2026, according to endoflife.date. Spring Boot 4.1 is supported until 31 July 2027. A team that spends the autumn moving from 3.5 to 4.0 will find itself out of free support again roughly ten weeks after today.

This matters because Spring is not a niche dependency. In JetBrains' State of Java 2025 report, Spring leads Java web frameworks at 65% usage. For a large share of European and US back-office, fintech, insurance and e-commerce systems, the Spring support calendar is effectively the security patch calendar.

Why Is Spring Boot 4.0 the Wrong Destination?

The instinct after an end-of-life notice is to move to the next major version and declare victory. With Spring in late 2026, that instinct produces a migration that has to be repeated almost immediately. The heavy lifting sits between 3.5 and 4.0: the Jakarta EE level, the Jackson major version, the starter layout and the removal of deprecated APIs. Moving from 4.0 to 4.1 afterwards is a much smaller step, but it is still another round of dependency updates, regression testing and production rollout that a team has to schedule.

Going straight to 4.1 avoids paying for two releases. The official Spring Boot 4.0 migration guide still applies, because 4.1 builds on 4.0, and the 4.1 release notes add their own smaller set of changes. Planning against 4.1 from the start means one dependency freeze, one regression cycle and one production cut-over.

It also gives the work a realistic deadline. 4.1's free support runs to the end of July 2027, so a team that starts in November has time to migrate carefully, service by service, instead of rushing a big-bang upgrade into the December change freeze that most enterprises already run.

There is one more reason to treat 4.0 as a waypoint at most. Spring Framework 7.0 itself is supported until July 2027 according to endoflife.date, longer than Boot 4.0. The short window belongs to the Boot 4.0 line specifically, and the way out of it is the next Boot release, not more time on 4.0.

What Does Running Unsupported Spring Actually Cost?

The cost of an end-of-life framework is not visible on the day support ends. It becomes visible the first time a CVE lands and the fix is not available for your version. Spring already provided a concrete example this summer. On 20 August 2026 the Spring team published CVE-2026-59313, a Server-Sent Events stream corruption issue in the Spring MVC functional web framework affecting every line from 5.3 to 7.0.8. The only open-source fix was Spring Framework 7.0.9. The in-branch fixes for 6.2, 6.1, 6.0 and 5.3 were all marked Enterprise Support Only.

The severity is also a lesson in how compliance tooling behaves. Spring rated the issue Low, but as HeroDevs documented, the CVE record received a 9.8 Critical score from CISA's ADP program because Spring's record carried no score. Many vulnerability scanners read the CVE record, not the vendor advisory. A team on Spring Framework 6.2 could therefore face a critical finding in its scanner, an auditor asking for remediation, and no free patch, all for an issue its own vendor considers minor.

That leaves three options, and none of them is free. The first is to buy commercial support, which extends Spring Boot 3.5 to 2032 through VMware Tanzu, or to buy third-party extended support such as HeroDevs. The second is to document, risk-accept and mitigate each finding one by one. The third is to upgrade. Paid support is a reasonable bridge for systems near retirement, but for software you plan to keep for years it postpones the migration rather than replacing it.

For regulated companies the calculation is sharper. Supply-chain obligations under NIS2, the operational resilience demands of DORA in financial services and the vulnerability handling duties of the Cyber Resilience Act all assume you can patch known vulnerabilities in a reasonable time. An unsupported framework at the core of a production system is hard to defend in any of those conversations.

What Actually Breaks Between 3.5 and 4.x?

The Spring Boot 4 migration is not the javax-to-jakarta trauma of Boot 3, but it is broader than most teams expect. According to the official migration guide, Spring Boot 4 targets Jakarta EE 11 with a Servlet 6.1 baseline, requires Spring Framework 7, keeps Java 17 as the minimum and requires Kotlin 2.2 or later. Undertow support has been removed entirely because Undertow does not yet support Servlet 6.1, so any service running on embedded Undertow has to move to Tomcat or Jetty.

Jackson 3 is the change that will touch the most code. It is now the default JSON library, with new group IDs and packages under tools.jackson, while jackson-annotations keeps its old identifiers. The guide notes that @JsonComponent and @JsonMixin become @JacksonComponent and @JacksonMixin, and that Spring Boot now auto-configures a JsonMapper rather than an ObjectMapper. InfoQ's release coverage also points out changed defaults, including alphabetical property ordering and ISO-8601 date serialisation. Those are the dangerous changes, because they compile cleanly and alter the JSON your API consumers receive.

Spring Boot itself has been modularised. The monolithic autoconfigure jar is split into technology-specific modules, starters follow a spring-boot-starter-technology pattern, and older names such as spring-boot-starter-web are deprecated in favour of spring-boot-starter-webmvc. Some technologies that used to work with a plain library dependency, including Flyway and Liquibase, now need their own starter. If a migration is missing one, the symptom is not a compile error but auto-configuration that silently does not run.

Finally, everything deprecated during the 3.x lifecycle has been removed. In tests, @MockBean and @SpyBean are gone in favour of @MockitoBean and @MockitoSpyBean, and @SpringBootTest no longer configures MockMvc or TestRestTemplate automatically. Spring Framework 7 also completes the move to JSpecify null-safety annotations, which the migration guide warns can cause compile failures for Kotlin projects and teams using null checkers. Each item is small. Across a portfolio of thirty services built by different people over several years, they add up to weeks of work.

How Much of This Can OpenRewrite and AI Agents Do?

A lot of it, and you should use them. OpenRewrite publishes an UpgradeSpringBoot_4_0 recipe that chains upgrades to Spring Framework 7, Spring Security 7, Spring Cloud 2025.1 and Spring Batch 6, renames starters, migrates properties, replaces @MockBean, moves Testcontainers to 2.x and adds the missing @AutoConfigure annotations. Note the licensing: the recipe is published under the Moderne Source Available License, which allows non-commercial use from source, so check the terms before running it in a commercial pipeline.

AI coding agents add a second layer. Amazon is the best-documented example. In August 2024 Andy Jassy wrote that using Amazon Q Developer, the average time to upgrade an application to Java 17 fell from 50 developer-days to a few hours, and that developers shipped 79% of the auto-generated code reviews without further changes. AWS later described savings of over 4,500 years of development work across tens of thousands of production applications. Those are Amazon's own estimates, achieved with a large platform team behind the tooling, but they show the direction clearly.

The useful reading of those numbers is that mechanical changes are now cheap. Renaming imports, swapping annotations and updating build files is exactly the work where recipes and agents excel. What they do not do is decide whether alphabetical JSON property ordering breaks a partner integration, whether a removed Undertow-specific tweak was protecting a performance edge case, or whether a missing Flyway starter means migrations silently stopped running in staging.

In practice that shifts the cost of a Spring upgrade from typing to verifying. The teams that move fastest pair automated rewriting with strong contract tests, consumer-driven API checks and observability that compares old and new behaviour in production. Where those tests do not exist, the first part of the migration is writing them, and that is where experienced Spring engineers earn their keep.

A Six-Week Upgrade Plan for a Typical Service Portfolio

For a portfolio of ten to forty Spring services, a disciplined migration to 4.1 fits into roughly six weeks of focused effort by a small team, provided the services already have reasonable test coverage. The plan below is the sequence we use with clients, and it follows the order the Spring team itself recommends.

Week one is inventory. List every service, its Spring Boot and Java versions, its embedded server, its JSON customisations and the external consumers of its APIs. JetBrains' State of Java 2025 found that 31% of developers still use Java 8 regularly, so it is common to discover a forgotten service that cannot even reach the Java 17 baseline. Those services need a separate track, because they face a bigger jump than everything else.

Week two moves every service to the latest 3.5.x and clears deprecation warnings, which the migration guide lists as the first step. Anything deprecated in 3.x is removed in 4.0, so fixing deprecations on 3.5 turns a stack of 4.0 compile errors into ordinary refactoring that can ship independently. In the same week, add contract tests that snapshot the JSON each service emits today.

Weeks three to five are the upgrade itself, one service or one group of services at a time. Run the OpenRewrite recipe, add spring-boot-properties-migrator to surface renamed properties at startup, and use the transitional classic starters and the spring.jackson.use-jackson2-defaults property where you need to separate the starter change from the Jackson behaviour change. Compare JSON snapshots, deploy to staging, then canary in production. Week six removes the transitional scaffolding, the properties migrator and the Jackson 2 compatibility settings, so they do not become the next layer of technical debt.

Should Your Product Team Do This, or a Dedicated Partner?

A framework upgrade is the textbook example of important but not urgent work. It produces no feature, it competes with every roadmap item, and it tends to be assigned to whichever engineer has a quiet sprint. That is how organisations end up on unsupported versions: nobody decided to stay on 3.5, it simply never reached the top of the backlog. With the 4.0 deadline at the end of December and year-end change freezes in between, that pattern is risky this year.

This is the kind of work where a nearshore dedicated team performs best. The scope is clear, the acceptance criteria are objective, the work is parallelisable across services, and it benefits from engineers who have already done the same migration elsewhere. At Stepto, our Serbian Java and Spring engineers work in the Central European time zone, with full overlap for EU clients and a solid morning overlap with US East Coast teams, so the people doing the upgrade can join your stand-ups and code reviews rather than handing over a zip file at the end.

The model also protects your product team. While a Stepto team runs inventory, deprecation cleanup, contract tests and service-by-service upgrades, your own engineers keep shipping features, and they review and approve rather than type. Because we combine OpenRewrite and AI coding agents with human review of every behavioural change, clients get the speed of automation without accepting AI-generated changes they cannot explain.

If you want to test the fit before committing, our two-week paid trial is long enough to complete the inventory and migrate a first pilot service, which gives you a realistic estimate for the rest of the portfolio. Dedicated teams typically onboard within two to four weeks from the first call, which still leaves time to move the most exposed services before Spring Boot 4.0's free support ends.

What Should Engineering Leaders Do Before 31 December?

Start by finding out where you stand. Most teams can answer in an afternoon how many services run on Spring Boot 3.5 or older, how many run on 4.0, and how many have a scanner finding that only a commercial or 7.0 release can close. That one number, services on an unsupported line, is worth putting in front of leadership this quarter.

Then make the version decision explicitly. Services that will be retired within a year may be candidates for paid extended support. Everything else should target Spring Boot 4.1 directly, and any team mid-way through a 3.5 to 4.0 upgrade should check whether it can retarget to 4.1 before its production rollout.

Finally, decide who does the work and give it a date. A migration that is everyone's side project is a migration that will still be running when the next end-of-life notice arrives. Whether you staff it internally or bring in a dedicated nearshore team, the upgrade needs an owner, a service-by-service plan and a finish line well before July 2027.