Spring AI 2.0 Is Coming Soon. Your Boot 4.0 Migration Does Not Have to Start Tomorrow.

Spring AI 2.0 GA is scheduled for May 28. The Spring team has spent months building on the foundation established in the 1.x releases, and 2.0 represents a significant platform step: a Spring Boot 4.0 baseline, null safety via JSpecify across the full API surface, Jackson 3 integration, and a stabilized, coherent API that teams can build enterprise AI applications on with confidence.

For teams that have been building on Spring AI 1.x, the Advisor framework, VectorStore abstraction, and RAG support are already familiar — those shipped in 1.0. What 2.0 delivers is a cleaner, more consistent API built on the modern Spring Boot 4.0 platform, with the rough edges of the early 1.x releases resolved and a stable dependency model teams can commit to for the long term.

It also requires Spring Boot 4.0. This is not a recommendation or a preferred configuration. Spring AI 2.0 is built on the Boot 4.0 dependency model and cannot be loaded in a 3.x context. That architectural constraint is the source of most of the migration complexity teams on Spring Boot 3.x need to plan for.

‍

What Boot 4.0 actually changes from 3.x

Spring Boot 4.0 is a genuine major version increment — the most significant release since the move to Jakarta EE in 2022. It is worth understanding the changes concretely before estimating migration scope.

Java 17 minimum, Java 21+ recommended. Boot 4.0 keeps the Java 17 minimum baseline. However, Java 21 or later is recommended to take advantage of virtual threads and other modern features that Boot 4.0 auto-configures. If your environment is on exactly Java 17, upgrading your JDK is worth planning for — it touches Dockerfiles, CI/CD pipelines, and local development environments before application code changes.

Auto-configuration model changes. Boot 4.0 ships smaller, focused auto-configuration modules rather than the single large spring-boot-autoconfigure jar. Applications with custom auto-configuration classes will need review. Third-party libraries that have not released Boot 4.0 compatible versions are hard blockers — identify them before committing to a timeline.

Jackson 3. Boot 4.0 moves from Jackson 2 to Jackson 3, which involves a group ID change, package renames, and Spring Boot class renames. Jackson 3 is the most likely change to cause production incidents on teams that don't test thoroughly — date serialization defaults and property ordering defaults change silently with no compiler warning. Clients that depend on specific JSON output shapes will break.

JSpecify null safety. Spring Boot 4.0 and Spring Framework 7.0 adopt JSpecify annotations as the null safety standard across the entire portfolio, deprecating Spring's own org.springframework.lang annotations. This is largely additive — your code compiles and runs unchanged — but adding @NullMarked to your own packages will surface nullability issues you did not know existed.

Removed deprecated APIs. Everything deprecated in the 3.x line has been removed in 4.0. The recommended migration path is to upgrade to Spring Boot 3.5.x first, resolve all deprecation warnings, and then migrate to 4.0. Teams not yet on 3.5 have two sequential steps before they can begin the 4.0 work.

None of these changes is insurmountable — OpenRewrite recipes automate much of the mechanical work. But Boot 4.0 migration is a multi-layer review-and-update exercise, not a dependency bump.

‍

Why May 28 is not the day to rush the migration

Spring AI 2.0 releases May 28. Spring Boot 3.5 and Spring Framework 6.2 reach end of life June 30 — 49 days from today, 33 days after the Spring AI 2.0 GA.

That timeline gap creates pressure. And pressure is exactly what produces bad migration outcomes — teams compressing scope, skipping validation steps, and accepting production risk in order to make a calendar deadline.

A Boot 4.0 migration that begins May 28 and targets June 30 has 33 days. For a team that has not yet done a dependency compatibility audit, a deprecated API cleanup pass, an auto-configuration review, a Jackson 3 compatibility check, a test coverage analysis, a migration implementation, an integration test cycle, a staging deployment, and a production rollout — 33 days is not enough time for any non-trivial production system.

The teams that will get the most out of Spring AI 2.0 are the ones who arrive at Boot 4.0 through a deliberate migration — not a sprint to beat a deadline.

‍

The parallel track approach

There is a practical path that does not involve either rushing the Boot 4.0 migration or running unpatched from July 1. It runs two tracks simultaneously.

Track one: secure the June 30 EOL exposure. If your Boot 4.0 migration will not complete before June 30 — and the realistic assessment for most enterprise teams is that it will not — get NES for Spring in place before the deadline. NES provides continued CVE monitoring and security patch backporting for Spring Boot 3.5 and Spring Framework 6.2 after the EOL date. Your production application stays patched while the migration proceeds. Enterprise procurement cycles typically run 30 to 60 days — the window to close a contract before June 30 is measured in weeks.

Track two: plan the Boot 4.0 migration with Spring AI 2.0 as the destination. Once Spring AI 2.0 GA ships May 28 and the API surface is stable, evaluate the full migration scope against a fixed target. Start with a dependency compatibility audit and deprecated API cleanup. Assess third-party library readiness for Boot 4.0. Build the test coverage needed to validate the migration at each layer. Set a migration timeline that reflects the actual scope — not the urgency of the June 30 deadline, which NES is handling.

The two tracks are not in competition. NES for Spring provides the security foundation from which the Boot 4.0 migration can happen properly. Spring AI 2.0 is the destination that makes the migration worthwhile.

‍

What to evaluate once Spring AI 2.0 ships

Once the May 28 GA lands, the evaluation work that has been waiting can begin. A few areas worth prioritizing before committing to a migration timeline:

Chat model integration. Review how your 1.x chat model configuration maps to the 2.0 API surface. The Advisor framework is stable and well-documented — assess how your existing advisor usage aligns with the 2.0 patterns and whether the Jackson 3 migration affects your serialization configuration.

Vector store and RAG pipeline. If you use vector stores for RAG or semantic search, review your existing VectorStore and RetrievalAugmentationAdvisor usage against the 2.0 implementation to identify any migration work.

Boot 4.0 auto-configuration changes affecting AI beans. Review how your Spring AI beans are configured and whether the modular auto-configuration changes affect their initialization. This is the area most likely to surface unexpected issues mid-migration.

Third-party library compatibility. Audit your full dependency tree for Boot 4.0 and Jackson 3 compatibility. Libraries that have not released compatible versions are hard blockers — identify them before committing to a migration timeline.

This evaluation work takes days, not hours. Starting it once the GA lands — before the migration implementation begins — is what prevents mid-migration surprises.

‍

FAQ

Does Spring AI 2.0 work on Spring Boot 3.x? No. Spring AI 2.0 requires Spring Boot 4.0. It is built on the Boot 4.0 dependency model and cannot be loaded in a 3.x context. Teams on Spring Boot 3.x must complete the Boot 4.0 migration before adopting Spring AI 2.0.

What are the main changes in Spring Boot 4.0 from 3.x? Spring Boot 4.0 keeps a Java 17 minimum with Java 21+ recommended, ships with Spring Framework 7 and Jackson 3, introduces a modular auto-configuration architecture, adopts JSpecify null safety annotations, and removes all APIs deprecated in the 3.x line. The recommended migration path is to upgrade to Spring Boot 3.5.x first and resolve all deprecation warnings before moving to 4.0.

How long does a Spring Boot 3.x to 4.0 migration take? For enterprise production environments the realistic range is several months when accounting for dependency compatibility, deprecated API cleanup, Jackson 3 migration, test coverage updates, integration testing, and staged deployment. Rushing a migration to fit a 33-day window creates production risk that is not worth accepting.

What happens to Spring Boot 3.5 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 no longer issue security patches, CVE remediations, or any updates for these versions.

How can teams adopt Spring AI 2.0 without rushing the Boot 4.0 migration? Teams can secure NES for Spring to maintain security patching on Spring Boot 3.5 and Framework 6.2 after the June 30 EOL, giving them the runway to plan and execute a proper Boot 4.0 migration. With NES in place, the migration timeline is a technical and organizational decision — not a security emergency.

What is new in Spring AI 2.0 compared to 1.x? Spring AI 2.0 is built on a Spring Boot 4.0 baseline with Spring Framework 7, moves to Jackson 3, gains null safety via JSpecify, and delivers a stable, coherent API surface. The Advisor framework, VectorStore abstraction, and RAG support were introduced in 1.0 and are matured and stabilized in 2.0.

Is NES for Spring a permanent alternative to upgrading? No. NES for Spring is designed as a migration bridge. 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.