Spring Boot 3.x Is EOL: Upgrade, Buy Runway, or Accept Risk

For a meaningful share of Java estates, upgrading straight away is the wrong call. This guide gives you the neutral version of the decision, the one count that predicts which option fits, and a one-week method for turning it into a table your finance team can sign.

Every Spring Boot 3.x branch is now outside open-source support. Spring Boot 3.5.16 shipped on 25 June 2026, there will be no 3.5.17, and free support for 3.5 ended five days later.

Version 3.4 had already lost free support in December 2025, and 3.3 in June 2025. If you run 3.x in production, and most mature Java estates do, you no longer receive free patches.

That is not the same as running unpatched code. Commercial support still ships fixes for 3.4 and 3.5. But nothing reaches you unless you pay for it or move.

None of this is a surprise. The Spring support policy (opens in a new tab) gives each minor release a minimum of 13 months of open-source support, then commercial support only.

One clause in that policy changes everything. The last minor version of a major line gets an extra five years of enterprise support. Spring Boot 3.5 is that last minor, so commercial patches for it run until June 2032.

That clause turns a migration ticket into a three-way decision. Most of what you will read on this topic comes from companies selling migration tooling or extended support, and each argues for its own product. What follows argues for neither.

Upgrading is right for most teams, and for any estate that is still taking new features. Two things make it easier than the 2.x to 3.x jump was, and one thing makes it harder.

Easier: the Java baseline does not move. Spring Boot 4 requires Java 17 or later, the same floor as 3.x. If you finished the Jakarta EE namespace migration in 2023, you have already paid the most expensive tax.

Easier: much of the change is mechanical. Spring Boot 4 removes 36 deprecated classes, roughly 88% of all its deprecations, according to Moderne's migration guide (opens in a new tab). OpenRewrite's community recipe for 4.0 automates that kind of change deterministically. Moderne's recipe for 4.1 needs a paid subscription.

Harder: Jackson 3. Spring Boot 4 defaults to Jackson 3, whose group ID and packages move from com.fasterxml.jackson to tools.jackson. In your own code, that is close to a find-and-replace. The cost hides in the libraries you did not write.

Jackson 2 and Jackson 3 can sit on the same classpath, and Spring Boot 4 still manages Jackson 2 in a deprecated form. So a library that depends on Jackson 2 will not break your build. It will keep its own serialization settings, and the naming strategies, date formats and modules you configure in Spring will not reach it.

Every one of those libraries is a boundary someone has to check by hand. That checking, not the API change, is what breaks estimates. The audit is broken down step by step in What Spring Boot 4 Breaks: The Jackson 3 Blast Radius.

The rest of the change list is enumerable. Scope it before you commit to a date.

Expect the test layer to churn on its own, independent of application code. Spock integration, removed in 4.0, returns in 4.1.

Spring recommends moving to the latest 3.5.x and clearing deprecation warnings before you start. There is no separate 3.5 to 4.1 guide, so work through the 4.0 migration guide and then the 4.1 release notes, even if 4.0 never reaches production.

Choose the upgrade when:

• The estate is still taking features, so supportability is not the only thing you gain.
• Only a handful of libraries you do not control still depend on Jackson 2.
• You have, or can free, the engineering capacity in the next two quarters.

Buy runway when a migration would buy you nothing but supportability, or when its cost would land at the worst possible moment. It is a legitimate option, and correct more often than migration vendors admit.

Commercial support keeps 3.5 patched until June 2032. You are not choosing between safety and cost. You are choosing which line item the cost lands on.

It is the right call when at least two of these hold:

• The estate is in feature freeze or maintenance mode.
• Your dependency audit finds heavy Jackson 2 use in libraries you cannot upgrade or fork.
• A regulatory or contractual deadline owns your engineering capacity for the next two quarters.
• The application is due to be retired or replaced within three years. Migrating something you intend to retire is pure waste.

There are two kinds of supplier. Broadcom sells patches for 3.5 through its Tanzu Spring (opens in a new tab) subscription, and third parties such as HeroDevs (opens in a new tab) sell extended support for older Spring Boot lines.

Neither publishes a list price. Both are quote-only. HeroDevs describes its subscription as typically less than one engineer-month of internal work, but that is a vendor's framing, not a benchmark.

Treat it as a hypothesis and get two quotes. Anyone who gives you a per-core price for Spring support without a quote in hand is guessing.

The catch is that runway is not a strategy. If you buy time to 2032 and do nothing with it, you will have this conversation again with a worse codebase and fewer people who remember how it works.

Only for internal systems that are not exposed to the internet and are due to be retired soon. Even then, write it down as an accepted risk with a named owner and a review date. Otherwise it is not a decision. It is drift.

Understand what you are accepting, because it is worse than your dashboard suggests. When a branch reaches end of life, its vulnerabilities do not stop existing.

Researchers move to supported versions, maintainers stop triaging the old branch, and fewer vulnerability identifiers get assigned against it. Your scanner turns green because nobody is filing against the code, not because the code got safer.

Poole works for HeroDevs, which sells extended support, so weigh the argument with that in mind. The mechanism he describes is not in dispute.

Spring Boot 2.7 is the worked example. CVE-2024-38807 (opens in a new tab), a signature forgery flaw in the Spring Boot loader, was published in August 2024, nine months after open-source support for 2.x ended. The fix for 2.7 went only to commercial customers.

Its scope was narrow: it affected applications that verify signatures on nested jars. But the pattern is the point.

Poole is careful to say that nobody has rigorously measured this effect, and that honesty matters. So does this: "no CVEs reported" and "no vulnerabilities present" are different statements. On an end-of-life branch, only the first is measurable.

Each option fails in a predictable way, and each failure has a cheap early warning. Watch for these before they become the story of the project.

Run four steps, in this order. They take about a week, and they are the whole job.

1. Count the libraries you do not control that still depend on Jackson 2. Run the dependency analysis across every module. Our rule of thumb: below five, upgrade. Above fifteen, with no upstream releases in sight, price the runway.
2. Estimate engineer-days from your own history, not from a blog. Take the real effort of your 2.x to 3.x migration and scale it by how much the codebase has grown. Discount the mechanical share for recipe automation, starting at 30 to 50%, then replace that assumption with a trial run on one service.
3. Get two extended-support quotes, even if you intend to upgrade. It costs a few calls, and it turns your business case from an assertion into a comparison.
4. Price the do-nothing column honestly. It is not zero. It is the expected cost of a breach times its probability, plus audit findings, plus a migration that gets harder every year you defer it.

A borrowed per-line figure is worthless in step 2, because the variance sits in your dependency tree, not your line count.

The output is a three-column table: engineer-days, subscription cost and accepted risk, in the same units. Most teams have never built it, which is why this decision usually goes to whoever argues loudest.

If you choose the upgrade and plan to put AI coding agents on it, read where AI agents help a Java migration, and where they lie before the first run.

Only commercially. Open-source support for 3.5 ended on 30 June 2026, and 3.5.16 was the last free release. Because 3.5 is the final minor of the 3.x line, Spring's policy adds five years of enterprise support, so paying customers receive patches until June 2032. Everyone else receives nothing further.

Yes, as one project. Spring recommends moving to the latest 3.5.x and clearing deprecation warnings first. There is no dedicated 3.5 to 4.1 guide, so work through the 4.0 migration guide and then the 4.1 release notes in order. Version 4.0 never has to reach production.

No. Spring Boot 4 requires Java 17 or later, the same minimum as 3.x, and supports versions up to Java 26. It does raise other baselines: Spring Framework 7, Jakarta EE 11 with Servlet 6.1, Kotlin 2.2 and GraalVM 25 for native images. Check those before assuming the jump is free.

Nobody publishes a figure. Broadcom's Tanzu Spring subscription and third-party extended support from vendors such as HeroDevs are sold by quote only. HeroDevs describes its price as typically less than one engineer-month of internal work, but treat that as vendor framing. Get two quotes before a number goes into a business case.

The application keeps running, but no free fixes arrive for new vulnerabilities, and fewer of those vulnerabilities get reported at all. Your scanner can look cleaner while your real exposure grows. If you stay, record it as an accepted risk with an owner, a review date and a retirement date.

Only if your migration will finish after November 2026, when Spring's schedule lists the 4.2 release, with open-source support until December 2027. A team starting now should still target 4.1 and treat 4.2 as the next minor upgrade. Waiting for it leaves you on an unsupported branch for longer.

The mistake is not choosing wrong. It is not knowing there was a choice. If you want the table built from your own dependency graph, that is the first week of our legacy software modernization work.

• Spring support policy (opens in a new tab), Spring
• Spring Boot 4.0 Migration Guide (opens in a new tab), spring-projects wiki
• Spring Boot 4.1 Release Notes (opens in a new tab), spring-projects wiki
• Spring Boot End of Life: Every 3.x Branch Is Now Unsupported (opens in a new tab), Dan Vega
• Crossing the River Styx: Spring Boot 3.5 and the Zombie Dependency Problem (opens in a new tab), Steve Poole, foojay.io
• CVE-2024-38807: Signature Forgery Vulnerability in Spring Boot's Loader (opens in a new tab), Spring
• How to speed and scale your Spring Boot 4 migration (opens in a new tab), Moderne
• Spring Boot Versions, EOL Dates, and Latest Releases (opens in a new tab), HeroDevs