Spring Boot Migration Analyzer

Why a blind javax → jakarta find-and-replace breaks your build

The headline change when you upgrade from Spring Boot 2 to Spring Boot 3 is the move from Java EE to Jakarta EE 9+, which renames the specification packages from javax.* to jakarta.*. The obvious shortcut — a project-wide search-and-replace of javax with jakarta — is also the most common way to break a working codebase. The reason is simple: not every javax.* package is a Jakarta EE package. A large set of javax.* packages ship as part of the JDK itself and were never part of Java EE, so they keep the javax prefix forever.

If your service does TLS, message encryption, database access, JNDI lookups or XML parsing — the bread and butter of banking and payments integrations — a careless replace will rewrite javax.crypto, javax.net.ssl, javax.sql, javax.naming and javax.xml.parsers into packages that do not exist, and your build stops compiling. The analyzer classifies every import into two lists: migrate (a genuine Jakarta EE package, with the exact jakarta.* replacement) and keep (a JDK package, left untouched, with the reason it is safe). It even handles the tricky sibling splits — javax.transaction migrates but javax.transaction.xa stays; javax.xml.bind (JAXB) migrates but javax.xml.parsers (JAXP) stays; javax.annotation migrates but javax.annotation.processing stays.

What the analyzer checks

The tool has two upgrade paths, selected from the dropdown. Each rule set only fires where it applies, and every finding carries a severity badge (Blocker, Update, Review, Keep, or OK), the line number, a one-line fix, and a before → after code diff where a concrete rewrite exists.

Spring Boot 2.x → 3.x

• Namespace: every javax.* import classified migrate vs keep.
• Java baseline: flags java.version / sourceCompatibility below 17 (Spring Boot 3 requires Java 17).
• Spring Security 6: WebSecurityConfigurerAdapter, antMatchers(), mvcMatchers(), authorizeRequests(), @EnableGlobalMethodSecurity and their replacements.
• Hibernate 6 dialects: versioned dialects such as MySQL8Dialect and PostgreSQL95Dialect, plus storage-engine dialects, are deprecated in favour of the auto-detecting base dialect.
• Config properties: renames and removals including spring.redis.* → spring.data.redis.*, spring.datasource.initialization-mode → spring.sql.init.mode, server.max-http-header-size, spring.sleuth.* (now Micrometer Tracing), spring.session.store-type, and the SAML2 and httptrace renames.
• Removed classes and dependencies: HttpTraceRepository, type-level @ConstructorBinding, @EnableBatchProcessing, the Elasticsearch high-level REST client, and the mysql-connector-java → com.mysql:mysql-connector-j coordinate change.

Spring Boot 3.x → 4.0

• Modularized starters: spring-boot-starter-web → -webmvc, -aop → -aspectj, the -oauth2-* starters move under -security-oauth2-*, and Undertow support is removed.
• Package moves: EnvironmentPostProcessor, BootstrapRegistry, @EntityScan, @PropertyMapping, TestRestTemplate, and Spring’s @Nullable → JSpecify.
• Jackson 3: com.fasterxml.jackson → tools.jackson (the annotations package is correctly excepted), plus @JsonComponent → @JacksonComponent.
• Tests: @MockBean → @MockitoBean, @SpyBean → @MockitoSpyBean.
• Properties: the MongoDB connection keys move from spring.data.mongodb.* to spring.mongodb.*, session and Jackson properties are re-nested, and spring-authorization-server.version folds into spring-security.version.
• Java baseline: Spring Boot 4 requires Java 17 as a minimum (Java 21+ is recommended for virtual threads — a point several guides get wrong by claiming 21 is mandatory).

How to use it

1. Choose your upgrade path from the Upgrade path dropdown.
2. Paste a single Java file, your pom.xml or build.gradle, or an application.properties/.yml block. Mixed input is fine.
3. Click Analyze. Findings appear grouped by category with a summary count at the top.
4. Work top-down: fix the red Blocker items first, apply the amber Update rewrites, then check each purple Review note by hand.

The four sample buttons load realistic examples for the selected path, so you can see exactly what the output looks like before pasting your own code.

What it deliberately does not do

The analyzer reads imports, configuration keys, starter and dependency artifact IDs, and well-known annotations and class names. It is a fast static scanner, not a full Java compiler, so it does not resolve fully-qualified type references buried mid-expression or deeply nested YAML structures. That is a conscious trade-off: its failure mode is a miss, never a wrong “fix.” Always compile and run your test suite after migrating, and for the long tail of renamed configuration keys, add Spring Boot’s own spring-boot-properties-migrator dependency (runtime scope) to get startup diagnostics. For automated, repository-wide rewrites, pair this tool with OpenRewrite’s Spring Boot migration recipes — the analyzer is for understanding and spot-checking; the recipes are for bulk mechanical change.

Frequently asked questions

More Java developer tools: Browse the full Java Developer Tools hub — including the application.properties ↔ YAML converter, the JSON Formatter, and the LLM Token Counter.