✦ Sample Prompt
Migrate every Spring Boot 2.x service to Spring Boot 3.2.

For each repository:
1. Update build files:
   - Maven: `<spring-boot.version>3.2.x</spring-boot.version>`, parent POM bump
   - Gradle: `id "org.springframework.boot" version "3.2.x"`
   - Bump Java target to 17 (`java.version` / `sourceCompatibility = '17'`).
     Spring Boot 3 requires JDK 17+.
2. Rewrite Jakarta EE imports across all Java source:
   - `javax.servlet.*` → `jakarta.servlet.*`
   - `javax.persistence.*` → `jakarta.persistence.*`
   - `javax.validation.*` → `jakarta.validation.*`
   - `javax.annotation.PostConstruct` / `PreDestroy` → `jakarta.annotation.*`
   - `javax.transaction.*` → `jakarta.transaction.*`
3. Apply property renames in `application.properties` / `application.yml`:
   - `spring.redis.*` → `spring.data.redis.*`
   - `server.servlet.context-path` (unchanged) but audit other `spring.*` renames
     from the 3.0 migration guide
   - Actuator endpoint exposure paths
4. Replace deprecated APIs:
   - `WebSecurityConfigurerAdapter` → `SecurityFilterChain` bean
   - `WebMvcConfigurer` defaults updated
   - `Trusted-proxy` server forward-headers config renamed
5. Update dependencies that have Jakarta-only releases (Hibernate 6, Tomcat 10,
   `springdoc-openapi-starter-webmvc-ui`).
6. Update CI to JDK 17.

The Problem

Spring Boot 3 requires JDK 17 and switches the entire ecosystem from `javax.*` to `jakarta.*` namespaces, the EE9 rename that propagated from the Jakarta EE project. Every Java source file using `javax.servlet`, `javax.persistence`, `javax.validation`, or `javax.annotation` needs its imports rewritten. Hibernate moves from 5 to 6, Tomcat from 9 to 10, and dozens of Spring-adjacent libraries shipped breaking majors at the same time.

Beyond the namespace move, Spring Boot 3 deprecated `WebSecurityConfigurerAdapter` in favour of the `SecurityFilterChain` bean style, renamed a long list of configuration properties (`spring.redis.*` → `spring.data.redis.*`, actuator path changes), and dropped support for older JDKs. At organizational scale (dozens of services on Spring Boot 2.x, each with its own custom security config, its own actuator exposure rules, its own pinned Hibernate version) coordinating the bump is a quarter-long programme. Manual migration with OpenRewrite recipes works per-repo, but herding every service through review and deploy is where teams stall.

What Tidra Does

  1. Bumps Spring Boot to the target 3.x version in Maven (<spring-boot.version>) or Gradle (org.springframework.boot plugin), and raises Java target to 17
  2. Rewrites javax.* imports to jakarta.* across all Java source (servlet, persistence, validation, annotation, transaction)
  3. Applies Spring Boot 3 configuration property renames in application.properties / application.yml (Redis namespace move, actuator paths, etc.)
  4. Replaces deprecated APIs, WebSecurityConfigurerAdapterSecurityFilterChain bean configuration, updated WebMvcConfigurer patterns
  5. Bumps dependencies that have Jakarta-only releases (Hibernate 6, Tomcat 10, springdoc-openapi-starter-webmvc-ui)
  6. Updates CI workflows and Dockerfiles to JDK 17 and opens a PR per service summarising changes and any deprecation TODOs

Before & After

diff
build.gradle
@@ -1,18 +1,18 @@
plugins {
- id 'org.springframework.boot' version '2.7.18'
- id 'io.spring.dependency-management' version '1.1.0'
+ id 'org.springframework.boot' version '3.2.5'
+ id 'io.spring.dependency-management' version '1.1.4'
id 'java'
}
java {
- sourceCompatibility = '11'
+ sourceCompatibility = '17'
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-web'
implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
- implementation 'org.springframework.boot:spring-boot-starter-security'
- implementation 'javax.validation:validation-api:2.0.1.Final'
+ implementation 'org.springframework.boot:spring-boot-starter-security'
+ implementation 'org.springframework.boot:spring-boot-starter-validation'
runtimeOnly 'org.postgresql:postgresql'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

Customization Tips

  • Target Spring Boot version: 3.2 is the safer mid-range target; 3.3 adds virtual threads support but tightens some defaults. Pick once for the whole org rather than per-service.
  • Security configuration: Services with heavily customised WebSecurityConfigurerAdapter subclasses need the most manual review. Flag those for human follow-up rather than blind rewrite.
  • Hibernate 5 → 6: Hibernate 6 changes the default ID generator behaviour and tightens type handling. Run integration tests against a real database before merging.
  • Phased rollout: Migrate low-risk internal services first to validate the org-wide library bumps, then move to customer-facing services once the dependency tree is proven.

Ready to run this across your repos?

Connect your Git provider and Tidra opens pull requests in every repo that needs them.