Spring AI 2.0 Is Coming May 28. Here Is Why That Makes the June 30 Deadline More Urgent, Not Less.
The Spring AI 2.0 launch is not a reason to wait on your EOL decision. It is a reason to act now.
The holding pattern that is narrowing your options
There is a specific pattern showing up in enterprise Spring conversations this quarter. A team knows about the June 30 Spring Boot 3.5 EOL. They know they need to do something. But Spring AI 2.0 GA is scheduled for May 28 — exactly 33 days before the EOL date — and the thinking goes: wait and see what AI 2.0 looks like, evaluate whether the Boot 4.0 migration makes sense, and then decide.
It sounds like reasonable sequencing. It is not. What this approach produces is a situation where a team has 33 days — from the May 28 AI 2.0 GA to the June 30 EOL — to either complete a major framework migration or accept running unpatched from July 1. Neither outcome is what the team intended when they decided to wait.
What reaches end of life on June 30
On June 30, 2026, two Spring versions reach end of life:
After that date, neither version will receive security patches, CVE remediations, or any updates from the Spring team. The release lines close.
It is worth being precise about what is not in scope here. Spring Boot 3.3 and Spring Framework 6.1 already reached end of life in June 2025. If your application is running those versions, the gap is not upcoming — it is current. Spring Boot 3.5 and Spring Framework 6.2 are what June 30 closes.
Spring AI 2.0 does not change these dates. The EOL dates are fixed regardless of when AI 2.0 ships, regardless of the state of the Boot 4.0 migration ecosystem, and regardless of where any individual team's migration stands.
What Spring AI 2.0 actually requires
This is the technical reality that makes the wait-and-see approach structurally problematic: Spring AI 2.0 requires Spring Boot 4.0 as a hard dependency. It is not a recommendation or a preferred configuration — it is an architectural requirement. Teams on Spring Boot 3.x cannot evaluate Spring AI 2.0 in their existing environment. The Boot 4.0 migration is a prerequisite.
Spring Boot 4.0 is a significant upgrade from 3.x. It requires Java 17 as a minimum (Java 21 recommended), ships with Spring Framework 7, moves to Jackson 3, introduces a new modular auto-configuration architecture, and removes all APIs that were deprecated in the 3.x line. The recommended migration path is to upgrade to Spring Boot 3.5.x first, resolve all deprecation warnings, and then migrate to 4.0 — meaning teams not yet on 3.5 have two sequential steps before they can even begin the 4.0 work.
For teams running large, complex Spring applications in enterprise environments — applications that have been in production for years, with dozens of dependencies, downstream integrations, and extensive test coverage — this migration is measured in months of engineering effort, not weeks.
Teams waiting for AI 2.0 before deciding on EOL coverage are left with 33 days to do a multi-month project. The math does not work.
The 33-day problem
The timeline is explicit. Spring AI 2.0 GA ships May 28. June 30 is 33 days later. For a team that has been waiting on AI 2.0 before deciding, May 28 is the day they learn what the Boot 4.0 migration actually involves. It is also the day they have 33 days until their Boot 3.5 application starts running unpatched.
Thirty-three days is not enough time to complete a Boot 4.0 migration for any non-trivial Spring application. It is not enough time for a dependency audit, a Java version upgrade, an API compatibility assessment, a deprecated-code cleanup pass, a test coverage review, a migration implementation, an integration test cycle, a staging deployment, and a production rollout. The teams whose Spring migrations go smoothly are the ones who started those steps months ago.
What the 33-day window produces in practice is one of two outcomes: a rushed migration that accepts production risk to make the calendar, or a team that misses the deadline and runs unpatched from July 1 while still planning the migration. Neither outcome is what was intended when the decision was made to wait for AI 2.0.
The budget objection and why it does not hold
In 2026, engineering budgets are under real pressure from AI investment priorities, and extended support contracts can look like discretionary maintenance spending. This creates genuine headwind for NES conversations in some organizations.
The framing that matters is this: NES for Spring is not a maintenance contract. It is the infrastructure that keeps production systems secure while the organization executes a complex technical migration on a timeline that reflects the actual scope of the work.
The Spring Boot 3.x CVE history since January 2026 includes multiple high-severity vulnerabilities with CVSS scores above 7.0 — including authentication bypass vulnerabilities in Spring Security and header injection issues directly affecting Spring applications. After June 30, vulnerabilities of that severity in Spring Boot 3.5 will not receive patches. That is not a maintenance cost avoidance story. It is a documented security risk transfer to the organization.
What teams should do now
The practical path for teams on Spring Boot 3.5 is two parallel tracks, not a sequential decision.
First, secure June 30 EOL coverage. If your Boot 4.0 migration timeline extends past June 30 — and for most enterprise teams doing the migration properly, it will — get NES for Spring in place before the EOL date. Enterprise procurement cycles typically run 30 to 60 days. The comfortable window to close a contract before June 30 is weeks away. That window is narrowing.
Second, start Boot 4.0 migration planning now, with Spring AI 2.0 as the destination architecture. Use the security runway that NES coverage provides to evaluate the AI 2.0 API surface, assess your 3.x to 4.0 migration scope properly, build the integration test coverage needed to validate the migration, and execute the rollout in a way that does not put production at risk.
Spring AI 2.0 is worth getting to. The teams that will get the most out of it are the ones who arrive at Boot 4.0 through a deliberate, tested migration — not the ones who compressed the timeline to 33 days and took on production risk to make the calendar.
FAQ
What Spring versions reach end of life on June 30, 2026? Spring Boot 3.5 and Spring Framework 6.2 reach end of life on June 30, 2026. After that date, the Spring project will not issue security patches, CVE remediations, or any updates for these versions. Note: Spring Boot 3.3 and Spring Framework 6.1 reached EOL in June 2025 and are already past their end-of-life date.
When is Spring AI 2.0 GA releasing? Spring AI 2.0 GA is scheduled for May 28, 2026, approximately 33 days before the June 30 Spring Boot 3.5 EOL date.
Does Spring AI 2.0 work with Spring Boot 3.x? No. Spring AI 2.0 requires Spring Boot 4.0 as a hard dependency. Teams on Spring Boot 3.x cannot adopt Spring AI 2.0 without first migrating to Spring Boot 4.0. The two migrations are coupled and cannot be evaluated independently in a 3.x environment.
How long does a Spring Boot 3.x to 4.0 migration take? For enterprise production environments, a Spring Boot 3.x to 4.0 migration typically takes several months when accounting for Java version requirements, dependency assessment, deprecated API cleanup, test coverage updates, integration testing, and production rollout planning. The Spring team recommends upgrading to Spring Boot 3.5.x first before attempting the 4.0 migration, which adds an additional step for teams not yet on 3.5.
What is NES for Spring and what does it cover? Never-Ending Support (NES) for Spring provides continued CVE monitoring and security patching for Spring Boot 3.5 and Spring Framework 6.2 after the June 30 EOL date. NES allows teams to maintain a secure posture for their Spring 3.x applications while executing a planned migration to Spring Boot 4.0 on a timeline that reflects the actual complexity of the work.
Why should I not wait for Spring AI 2.0 before deciding on extended support? Waiting for Spring AI 2.0 before deciding on EOL coverage leaves your team with 33 days between the AI 2.0 GA date and the Spring Boot 3.5 EOL. That is not enough time to complete a Boot 4.0 migration for any non-trivial enterprise application. The result is either a rushed migration that accepts production risk or a team that misses the deadline and runs unpatched from July 1.
How does NES fit with a future Boot 4.0 migration? NES for Spring is designed as a migration bridge, not a permanent alternative to upgrading. When your team completes the Boot 4.0 migration, you transition off NES and onto the supported upstream release. NES provides the secure foundation from which a deliberate, well-tested migration can happen — eliminating the urgency-driven risk of a compressed timeline.
.png){kind=small}
.png)
