Spring Boot 3.5 EOL: What the Migration Really Takes

"I don't see a path where we're at a position where we can upgrade Spring to supported versions over the next year."

That's a healthcare technology lead talking about his current Spring estate. He's not alone. Across the engineering leaders we've spoken to, the same pattern keeps coming up: Spring migrations are taking longer than the support window allows. The window is closing fast.

Spring Boot 3.5 reaches open-source end of life on June 30, 2026. Based on our telemetry across HeroDevs Never Ending Suuprt customer environments, roughly 93% of observed Spring Boot activity maps to versions that are already EOL or within months of it. About 26% of that activity sits on Spring Boot 3.5, specifically, the largest single line in the dataset.

If your AI tool says it can migrate Spring Boot in a sprint, this post is for you.

‍

Most Observed Spring Boot Usage Is Sitting Below the Next Supported Line

The Spring Boot population isn't sitting safely on the next supported line. That's the clearest signal from six months of dependency telemetry across HeroDevs NES customer environments.

Spring Boot 3.5 is the most widely used version, and its open-source support ends on June 30. Spring Boot 4.0, the most natural migration target, reaches EOL six months later, in December 2026. Yes, Boot 4.1 and beyond will continue the roadmap, but for most enterprises right now, getting to 4.0 cleanly is the challenge. The onward path exists; the time to walk it is what's scarce.

Worth being transparent about the data: this is our NES customer base, which skews toward organisations already behind on migrations. The figures likely reflect the harder end of the spectrum. Even so, the pattern is consistent with what we hear from engineering leaders across the industry.

This isn't an upgrade-once-and-relax cycle. For many enterprises, Spring Boot migrations are becoming a recurring engineering line item: application inventory, dependency review, test remediation, regression testing, security validation, and production rollout.

‍

Customer Timelines Are Not Matching the Calendar

A FinTech engineering leader described a completed migration from Spring Boot 2.7 to 3.4 as a "Herculean lift." If 2.7→3.4 was Herculean, what does 3.5→4.0 look like?

A healthcare technology lead was more direct: "I don't see a path where we're at a position where we can upgrade Spring to supported versions over the next year." A senior platform engineer at a major travel platform, already moving from 3.5 toward 4.0, still framed six months as the minimum realistic timeline.

The data from our Spring NES customer base points the same way. Across roughly 75 organisations, only about 10% of Spring packages were current as of April 2026. Not a single organisation had its full Spring stack completely up to date. Around 68% were fully behind, meaning every Spring package they consumed was either past EOL or approaching it.

Bear that in mind when reading these numbers: these are NES customers, organisations already facing migration challenges. But the pattern is consistent across the conversations we're having more broadly.

Spring migrations are portfolio work. They require application inventory, dependency review, test remediation, release coordination, security validation, and evidence that auditors and customers can actually use.

‍

Where AI Helps

AI can help with a migration from Spring Boot 3.5 to 4.x. It works best as an accelerator: part of the plan, not a substitute for one.

It can identify repetitive cleanup work, generate first-pass test scaffolding, summarise deprecation warnings, and explain build or configuration failures. It helps developers reason through dependency changes faster, especially when paired with deterministic tooling, CI feedback, and human review.

For Spring Boot 4 specifically, AI may be useful for teams trying to understand changes to the new modular auto-configuration model. Spring Boot 4 breaks the old auto-configuration structure into smaller, more focused modules. That shifts dependency assumptions and can surface build-time or runtime configuration issues that weren't visible before. AI can help read those failures, map them back to migration guidance, and suggest next steps.

Those are real gains. They don't shorten the migration as much as vendors suggest.

‍

Where AI Runs Out of Road

AI starts to break down, where the migration stops being mechanical and becomes architectural.

The dependency graph problem. Spring Boot manages a curated dependency graph: Tomcat, Netty, Jetty, Thymeleaf, Hibernate, pgjdbc, Liquibase, and dozens more. When Boot goes EOL, that whole graph freezes. The CVEs don't.

In April 2026, HeroDevs delivered remediated packages for 24 unique upstream CVEs across Tomcat, Netty, Thymeleaf, Jetty, and pgjdbc, each tied to dependencies managed by the Spring Boot BOM. None of those were Spring Framework code. All of them were part of the dependency surface Spring teams carry, whether they're migrating or not.

AI can flag a vulnerable dependency or suggest a version bump. It can't reliably determine whether the patched version is compatible with the rest of the BOM, whether your internal security exceptions still apply, or whether the change breaks an integration path the test suite barely covers.

The Boot 4 platform shift. Spring Boot 4 introduces changes across Jakarta EE 11, Servlet 6.1, Spring Security 7, Jackson 3, JUnit 6, and the new modular auto-configuration model. The Spring team made deliberate, sweeping changes, clearing out years of deprecated APIs, reorganising package namespaces, and tightening the component model. The result is 83 documented breaking changes with an estimated 200–500 hours of migration effort depending on your codebase. (We wrote a full migration guide covering all three tiers of change if you want the detail.)

Some changes will show up at build time. Others may only surface in runtime behaviour, test failures, serialisation differences, authentication flows, or configuration assumptions that no longer hold.

Code can be built. Tests can pass. Production can still behave differently under real traffic, real identities, real data, and real downstream dependencies.

The Spring AI wrinkle. Teams that adopted Spring AI on Spring Boot 3.5 should verify its compatibility before assuming a clean path to 4.x. For those teams, AI adoption can add a dependency constraint to the migration plan rather than reducing the timeline.

‍

The Judgment Gap

A migration from Spring Boot 3.5 to 4.x carries real production risk. It's a framework and dependency migration. The shape of the platform around your application changes, not just the code inside it.

Teams need to account for Boot's modular structure, auto-configuration changes, Jackson 3, Spring Security 7, Jakarta EE 11 and Servlet 6.1 alignment, JUnit 6, managed dependency updates, and the behaviour of their own starters, integrations, and internal libraries.

That work doesn't show up cleanly in an AI-generated migration plan. A tool identifies patterns and suggests edits. An expert knows which changes are cosmetic, which affect runtime behaviour, which dependencies can move safely, and which paths need deeper validation before production.

The tiering matters here. Some Boot 4 changes stop the compiler cold; you'll know immediately. Others pass the build but crash at startup or runtime. The most dangerous category is the third: silent behavioural changes that sit undetected in production for months. At Spring I/O 2026, roughly 100 developers took a 15-question migration quiz on Boot 4. The mean score was 66%, meaning the average Spring developer is walking into this migration with about 50 hours of unplanned work already built in. Our Spring Boot 4.0 Migration Guide maps all three tiers, including a Spring Security 7 annex and callouts for the changes that are most consistently underestimated in effort estimates.

Scott Frederick, a committer to Spring and Apache Tomcat, now leading engineering on HeroDevs' Spring NES work, put it plainly:

"When Spring Boot versions go EOL, they stop getting dependency updates. But the dependencies don't stop getting CVEs. If you're on an EOL Spring Boot version, you'd better be watching your dependencies and overriding Boot's managed dependency versions with newer versions."

AI speeds up edits. Compatibility, security evidence, release risk, and production behaviour still belong to a human.

‍

CVE Pressure Isn't Waiting for Your Migration

In the first four months of 2026, the Spring ecosystem disclosed 37 CVEs. All of 2025 produced 17.

April 2026 alone produced 26. Across March and April combined, the severity mix included 4 Critical, 12 High, 17 Medium, and 4 Low vulnerabilities.

Teams should not assume the period after EOL will be quiet. The 2026 disclosure pattern suggests unsupported Spring Boot lines will face new vulnerability pressure quickly, especially through managed dependencies that continue to receive upstream fixes regardless of what Boot version you're on.

That matters because migration timelines and security timelines don't move at the same speed. Engineering may need months to complete a safe platform migration. Security and compliance teams may need evidence much sooner.

‍

Your Options Before June 30

Migration is the right long-term answer. The timeline has to be real.

‍

Path 1 is the cleanest exit if your team can get there. For many enterprises, that timeline isn't realistic. Spring touches too much of the stack to migrate safely in a single quarter without disrupting everything else on the roadmap. That's not a comment on engineering capability. It's simply that, for most of us, Spring APIs are embedded throughout our code.

Path 2: HeroDevs NES delivers remediated Spring Boot 3.5 packages at the same Maven coordinates your CI/CD already consumes, designed as a drop-in requiring minimal or no code changes in most environments. NES covers the managed dependency graph too, so you're not left maintaining ad hoc overrides for Tomcat, Netty, Jetty, Jackson, and Hibernate while migration work is underway. HeroDevs provides CVE analysis, signed artefacts, release documentation, and support evidence that security and compliance teams can use.

NES gives you coverage on the version you actually run, while migration continues at a pace the engineering team can sustain.

‍

Where This Leaves You

Spring Boot 3.5 EOL is June 30, 2026. The migration is real. The work is harder than AI marketing suggests.

AI can help teams move faster, but it can't replace the judgment required to validate dependencies, assess runtime behaviour, manage security exposure, and prove production readiness.

The teams that get this right will be the ones that start with an honest view of the platform, dependency, and validation work ahead.

If you're scoping a Spring Boot 3.5 to 4.x migration, the Spring Boot 4.0 Migration Guide is a good place to start. It maps the full change surface across all three tiers before you commit to a plan. Then use the Spring Migration Calculator to size the effort, and talk to us about where the timeline is likely to break.

HeroDevs is a CVE Numbering Authority and has been the original reporter on multiple Spring-ecosystem vulnerabilities patched in the last twelve months. Learn more about Spring Never-Ending Support, or read the companion analysis, Spring Boot 3.5 EOL: The Cliff Edge.

‍

Sources and References

• Spring Support Policy
• Modularising Spring Boot 
• Spring Boot 4.0 Migration Guide
• HeroDevs Spring Boot 4.0 Migration Guide eBook
• Spring Migration Calculator Tool 
• Bob McNees, Spring CVE Surge 
• Loiane Groner, Spring Boot 3 EOL to Spring Boot 4: A Production Upgrade Playbook

‍