Spring Boot 3.5 Is the Next One: How to Think About the Decision Before You Have to Make It

Spring Boot 3.5 reaches end of life in June 2026. If you're running it in production — and most enterprise Java shops are — you're about to be in the same position the Spring Boot 2.7 and Spring Framework 5.3 cohorts were in eighteen months ago: a version that ships, tests cleanly, and runs production traffic, with no upstream security patches coming for the next critical CVE.

The decision in front of you isn't really "should we migrate to Spring Boot 4." It's "when do we want to decide, and on whose timeline."

You have three options, and you're already executing one of them whether you've named it or not:

1. Migrate to Spring Boot 4 on your own engineering capacity, on a timeline of your choosing.
2. Buy Never-Ending Support (NES) for Spring Boot 3.5 when it reaches EOL, and migrate to 4 on a deliberate schedule.
3. Do nothing.

Most planning conversations frame this as a choice between options 1 and 2. In practice, most teams default into option 3 — not by decision, but by deferral. The migration keeps slipping to next quarter. No vendor contract gets signed. The application keeps shipping, the security team keeps escalating, and the cycle repeats.

‍

Why this matters more than the last EOL cycle

The Spring Boot 2.7 EOL conversation, back in late 2023, happened in a relatively quiet CVE environment. Teams that drifted past EOL had time to figure out their next move. The window between disclosure and meaningful exposure was measured in months, sometimes a year. You could plan.

That window has closed. CVE submissions to NIST were up roughly a third in Q1 2026 alone, with vendors like Apache (+170%), Chrome (+563%), and VMware (+181%) reporting sharp year-over-year jumps. The widely-cited cause is AI-assisted vulnerability discovery — frontier models being pointed at codebases that humans have already scanned, and finding things humans missed.

The numbers are uneven and the AI attribution is still contested. Fewer than 200 CVEs explicitly credit LLM-assisted discovery, and some researchers argue the surge is real but smaller than the headlines suggest. What isn't contested:

• Mandiant's 2026 M-Trends report puts the estimated mean time-to-exploit at negative seven days — meaning exploitation of newly disclosed vulnerabilities is now routinely occurring before a patch is available. In 2018, that same window was 63 days. The window didn't just shrink; it inverted.
• NIST acknowledged in April 2026 that it can no longer enrich every CVE submitted to the National Vulnerability Database. CVE submissions grew 263% between 2020 and 2025 and kept rising in Q1 2026. Going forward, NIST will enrich only a prioritized subset; everything else — including the existing backlog of CVEs published before March 1, 2026 — moves to a "Not Scheduled" status with no NIST-provided severity score or product enumeration.
• Spring specifically has seen a steady stream of disclosures across the ecosystem in 2026 — 30 CVEs in March and April alone, nearly double what the Spring ecosystem disclosed in all of 2025 (17 CVEs). That includes a coordinated batch of six CVEs in March, eight Spring Boot CVEs on a single day in April, seven Spring Security CVEs disclosed two days earlier, and five Spring AI CVEs on April 27. The severity mix has shifted up too: 4 Critical and 10 High in those two months, versus 1 Critical and 2 High in all of 2025. EOL versions are consistently affected and consistently unpatched upstream. The full per-CVE breakdown is in the HeroDevs Vulnerability Directory.

The half-life of "we'll patch it next quarter" is shrinking. For applications running supported software, this is uncomfortable but manageable — patches are still being released. For applications that have drifted past EOL, the option set shrinks: apply commercial support, accept the exposure, or migrate under pressure.

That's the environment your 3.5 → 4 decision will be made in. It's not the environment the 2.7 → 3 decision was made in.

‍

What end of life actually changes

When a Spring Boot version reaches EOL, the OSS project stops releasing fixes for new vulnerabilities. CVEs disclosed against that version remain unpatched in the public repository. Your build still works. Your tests still pass. Nothing visible changes.

What changes is your risk profile, on a delay. The next critical Spring CVE — and there will be one, given the current cadence — won't have a patch you can pull from Maven Central if you're on the EOL version. Your options at that moment shrink to: emergency migration under pressure, in-house backporting from the Spring 4 codebase, or accepting the exposure and documenting it for your auditors.

For organizations operating under any kind of compliance framework, that third option isn't really an option. SOC 2, PCI DSS, HIPAA, and FedRAMP all require timely remediation of known vulnerabilities. An unpatched, publicly disclosed CVE in production with no remediation record is exactly the finding that triggers a written exception, a committed remediation date, and a meeting with your auditor. Documenting compensating controls is possible but expensive, and it's getting harder to defend as auditors get more familiar with the EOL pattern.

This is the part most planning documents miss. The cost of staying on an EOL version isn't a line item you pay today. It's a contingent liability that comes due on a timeline you don't control — and that schedule has accelerated.

‍

Option 1: Migrate to Spring Boot 4

The option most teams default to in planning documents because it feels like the right answer — stay current, stay on the supported version, own the work.

Spring Boot 4 isn't a casual upgrade. The Spring team has raised the baseline for nearly every supporting library in the stack. Tomcat needs to move from 10.1 to 11. Jetty from 11 to 12.3. Servlet from 6.0 to 6.1. Hibernate from 6.5 to 7.1. Kotlin from 1.9 to 2.2. JUnit from 5.0 to 6.0. Jackson from 2 to 3. Undertow isn't compatible with Spring Boot 4 at all — teams using it have to switch servers entirely.

We built a Spring Boot 3 → 4 Migration Calculator that walks through these variables for your specific footprint and returns an estimated migration timeline in weeks.

What the calculator captures:

• Application count and average codebase size
• Team capacity allocated to the migration
• Direct Spring project dependencies (Boot, Framework, Data, Security, Cloud, Batch, Integration, Web)
• JDK, server, and supporting library upgrades
• Use of automated migration tooling like OpenRewrite

What it doesn't capture — and what tends to swallow migration timelines:

• Discovery work. Finding which services use which Spring features, which custom configurations will break, and which third-party dependencies have no Spring Boot 4-compatible version. This is almost always more than expected.
• The migration tax on every other roadmap item during the migration window. Teams typically lose 30-50% of feature velocity for the duration.
• Follow-on work after migration completes. Bugs found in production, performance regressions, downstream services that need their own updates.
• Compliance audit cycles that don't pause for your migration. If a SOC 2 Type II observation window or a FedRAMP continuous monitoring cycle overlaps with the post-EOL period, you'll be answering questions about unpatched CVEs in your in-flight migration whether the work is done or not.
• Opportunity cost. Senior engineers doing migration work are not doing the work that differentiates your product. In 2026, that competing work increasingly involves AI initiatives — and most engineering leaders have observed that AI projects don't seem to get deprioritized in favor of dependency upgrades.

There's also a new wrinkle in this cycle: the migration timeline competes directly with the CVE response timeline. If you're eight months into a fourteen-month migration when a critical CVE hits Spring Boot 3.5 post-EOL, you can't wait six more months to finish. You either backport the fix in-house — work your team probably doesn't want to specialize in — or you accept exposure during the remaining window.

Self-migration tends to be the right answer when you have engineering capacity that isn't competing with critical roadmap work, when you have a strategic reason to be on Spring Boot 4 beyond the EOL date, and when your timeline gives you enough runway to absorb both the baseline library upgrades and your compliance reporting cycles cleanly. It tends to be the wrong answer when it's been chosen by default — when no one has actually run the calculator and no one has named the alternatives.

‍

Option 2: Never-Ending Support for Spring Boot 3.5

Never-Ending Support is a commercial agreement where a vendor maintains your existing Spring Boot version after the OSS project stops — backporting security fixes for CVEs disclosed against newer versions, delivering patches you can drop into your build with no code changes on your side.

What you pay for:

• Continued security patches for the EOL version you're running, delivered in the same artifact format your team already consumes.
• Compatibility guarantees and SLAs on patch delivery for critical CVEs — particularly relevant when patch lag now translates to active exploitation in days, not months.
• Documentation and audit trails for the compliance frameworks that govern most enterprise Java environments. HeroDevs NES is compatible with SOC 2, PCI DSS, HIPAA, FedRAMP, NIS2, and ISO 27001, with patch delivery SLAs designed to satisfy the timely-remediation language those frameworks require.

What it doesn't do:

• It doesn't get you to Spring Boot 4. If you have a strategic reason to be on the latest version, NES doesn't replace migration — it buys you time to do the migration on a deliberate timeline instead of an emergency one.
• It doesn't cover application-layer bugs unrelated to security. It's a security and compliance product.

In a low-CVE-volume year, NES is insurance against a tail risk. In a high-CVE-volume year, it's operational infrastructure for handling a predictable stream of disclosures against software you can't easily replace yet. The break-even point arrives faster when there are more CVEs to respond to — and faster still when each one of those CVEs is something your auditor will eventually ask about.

‍

Option 3: Do nothing

The default option. Worth thinking through honestly, because most teams are paying for it without realizing it.

What it costs:

• Security team time. Every new CVE disclosed against your version generates work — triage, risk acceptance documentation, exception requests, executive briefings. In an environment where Spring is shipping multi-CVE batches every few months and AI-assisted discovery is widening the disclosure pipeline, that workload is no longer occasional.
• Audit friction in regulated environments. SOC 2, PCI DSS, HIPAA, and FedRAMP all expect documented remediation of known vulnerabilities within defined timelines. Running an EOL Spring version with active CVEs creates a recurring audit finding pattern: a documented vulnerability, no upstream patch, no internal patch, and a compensating-control narrative that gets harder to defend each cycle. HeroDevs has a whitepaper on quantifying these risks that walks through what this looks like in practice.
• Insurance and contractual exposure. Cyber insurance policies increasingly exclude or limit coverage for known unpatched vulnerabilities. Customer contracts in regulated industries often require security currency clauses that explicitly call out timely patching of disclosed CVEs.
• Emergency response cost when a critical CVE hits. Spring4Shell in 2022 cost most affected organizations significant unplanned engineering time and executive attention — and that was for a version that was still supported. The version that isn't supported is more expensive to remediate, not less.
• Loss of engineering optionality. The longer you sit on an EOL version, the more expensive future migration becomes, because the version gap widens and the institutional knowledge of the original codebase decays.

The do-nothing cost is the hardest to put on a slide because it's contingent and probabilistic. But it compounds — and the rate of compounding is faster than it was in the last EOL cycle. The next critical Spring CVE that affects EOL versions isn't a hypothetical you can defer thinking about. It's an event with a near-term arrival window, given the cadence of 2026 disclosures.

‍

This is a pattern, not a one-time decision

Spring Boot 3.5 is the version on the clock right now. But the same decision will land on your desk again — for Spring Boot 4 eventually, for whatever comes after that, and for every other framework in your dependency graph. Spring Boot 2.7 reached its OSS end of support in November 2023. Spring Framework 5.3 followed in August 2024. The teams running those versions today are making the same three-option choice we're describing here, just from the other side of EOL.

The point isn't that you have to pick NES for every version. The point is that "we'll deal with it when we get there" is itself a choice — and the cost of that choice depends on the CVE environment, the audit cycle, and the contractual obligations you happen to be holding when you get there. The environment the 2.7 cohort dealt with isn't the environment the 3.5 cohort is going to deal with.

‍

How to actually decide

Four questions, in roughly this order:

1. Is migration to Spring Boot 4 strategically valuable for your team, or is it maintenance work?

If you have a real reason to be on Spring Boot 4 — new features, ecosystem alignment, hiring — migration is investment. If you're migrating only because the OSS support window is closing, it's maintenance, and the question becomes whether to do it on your timeline or someone else's.

2. What's your timeline pressure, including CVE-driven and compliance-driven pressure?

If a SOC 2 observation window, PCI assessment, FedRAMP continuous monitoring cycle, customer contract renewal, or insurance renewal is forcing a decision in the next 90 days, NES is almost always the right bridge. If your security team is already escalating on the current Spring CVE batch and you have no clear remediation plan for the post-EOL versions in your stack, that's a different kind of timeline pressure pointing the same direction.

3. What's the opportunity cost of your engineering team's time, in a year when AI initiatives are eating the roadmap?

If your senior engineers are the constraint on shipping the next product cycle — and increasingly, on shipping AI-adjacent capabilities your competitors are also shipping — pulling them onto a multi-quarter migration is a strategic mistake even if the migration math looks clean in isolation.

4. What does "do nothing" actually cost your organization, in the next twelve months?

This is the number most teams haven't honestly calculated. Once you have it — and once you've calibrated it to the current CVE cadence and your current audit obligations rather than the cadence you remember from the last EOL cycle — the other two options start to price themselves.

‍

Where to start

If you want to size the engineering effort of a Spring Boot 3 → 4 migration for your specific footprint, the Migration Calculator is built for exactly that.

For broader context — Spring EOL timelines across versions, CVE tracking, and decision guidance — the Spring End-of-Life Resource Hub is the most up-to-date single source.

If you want to talk through your specific situation — including the cases where NES isn't the right answer — get in touch.

‍

Spring Boot 2.7 reached its OSS end of support in November 2023. Spring Framework 5.3 followed in August 2024.