Luca BertonEvery enterprise Java team has the same problem: thousands of RestTemplate calls scattered across hundreds of microservices, and Spring has been telling you to migrate to RestClient since Spring Boot 3.2. Manual migration is impractical at scale — one service might have 50 REST calls, each requiring syntax changes, error handling updates, and test modifications. Multiply by 200 services and you have a multi-quarter project that nobody wants to fund.
OpenRewrite solves this by treating code migration as an automated, repeatable, auditable transformation. You define recipes — declarative rules for code changes — and run them across your entire codebase. The tool parses your Java source into a lossless semantic tree (LST), applies transformations, and writes back syntactically correct code. No regex. No find-and-replace. Actual understanding of your code's structure.
Why RestClient, Why Now
Spring's RestClient (introduced in Spring Boot 3.2) replaces RestTemplate as the recommended synchronous HTTP client. RestTemplate is officially deprecated in the next Spring Framework release — this isn't a "maybe someday" migration, it's happening now. In Spring 5, both coexist: RestTemplate still works, RestClient is available, and teams can migrate incrementally. But the deprecation clock is ticking.
RestTemplate → RestClient: What Changes
- Fluent API — RestClient uses a builder-style fluent API similar to WebClient but without reactive dependencies. Cleaner code, better readability, easier to maintain.
- Unified error handling — Consistent status handler pattern replaces the fragmented ResponseErrorHandler approach. One pattern across all HTTP calls.
- HTTP interface clients — Declarative HTTP interfaces (like Feign but native Spring) work with RestClient. Define an interface, annotate methods, get an implementation. Dramatically reduces boilerplate.
- Observability built in — RestClient integrates with Micrometer observation out of the box. Every HTTP call is automatically instrumented for metrics and distributed tracing.
- Future investment — Spring's engineering effort goes into RestClient and WebClient. RestTemplate is deprecated in the next release — it gets security fixes only, no features.
The OpenFeign → Spring HTTP Interface Migration
Many enterprises also depend on OpenFeign (Spring Cloud OpenFeign) for declarative HTTP clients. Spring now offers a native alternative: HTTP interface clients backed by RestClient. This eliminates the OpenFeign dependency entirely.
OpenFeign → Spring HTTP Interfaces: Why Migrate
- Native Spring, no third-party dependency — Spring's declarative HTTP proxy support removes the need for the OpenFeign library. One fewer dependency in your BOM, one fewer CVE surface.
- Same developer experience — Define an interface, annotate with @GetExchange/@PostExchange, inject it. The DX is virtually identical to Feign's @FeignClient — but it's part of Spring Framework core.
- RestClient or WebClient backend — Choose synchronous (RestClient) or reactive (WebClient) as the underlying HTTP engine. Feign only supports blocking calls.
- Consistent observability — HTTP interface clients inherit RestClient's Micrometer integration. Uniform metrics and tracing across all HTTP calls without per-client configuration.
- OpenRewrite automates it — Recipes exist to transform @FeignClient interfaces to Spring HTTP interfaces. Same automated, auditable migration approach — run across all services simultaneously.
For regulated enterprises maintaining dozens of Feign clients across microservices, this is a significant supply chain simplification. Removing OpenFeign from your dependency tree means one fewer library to track for vulnerabilities, one fewer compatibility concern during Spring Boot upgrades, and cleaner SBOM documentation for CRA compliance.
Kubernetes Recipes
Practical guide for container orchestration and deployment — hands-on patterns you can use today.
View on Amazon →OpenRewrite: How It Works
OpenRewrite isn't a code generator — it's a code transformer. The distinction matters for regulated environments:
1. Parse into Lossless Semantic Tree (LST)
OpenRewrite parses your Java source into a tree structure that preserves everything — formatting, comments, import order, whitespace. When it writes back, the only changes are the ones the recipe specified. No spurious diffs that pollute your git history.
2. Apply Recipes
Recipes are composable transformation rules. The RestTemplate-to-RestClient migration isn't one monolithic transformation — it's a chain: replace builder patterns, update method calls, transform error handling, adjust return types, update imports. Each step is testable and reversible.
3. Generate Clean Diffs
Output is standard git diffs — reviewable, mergeable, revertible. Your existing code review process applies. No binary transformations, no magic. Every change is visible in your PR.
4. Run at Scale
Apply the same recipe across 10 or 1,000 repositories. Moderne (the commercial platform behind OpenRewrite) provides organisation-wide execution with progress tracking, failure handling, and batch PR creation.
The Compliance Angle: Why Automated Migration Beats Manual
For regulated enterprises under DORA, NIS2, and CRA, code migrations carry compliance obligations. Automated, recipe-driven migration addresses these better than manual refactoring:
Microsoft SQL Server Performance Tuning
Performance tuning essentials for SQL Server. In collaboration with Starweaver.
Start on Coursera →Beyond RestClient: The OpenRewrite Recipe Catalogue
RestTemplate migration is one recipe among thousands. The OpenRewrite ecosystem covers the full spectrum of Java modernisation:
High-Value Recipes for Regulated Enterprises
- Spring Boot 2.x → 3.x migration — Jakarta namespace, removed deprecated APIs, property changes, security configuration updates. The most impactful single recipe for enterprises still on Spring Boot 2.
- Java 8/11 → 17/21 migration — Replace deprecated APIs, adopt records, pattern matching, sealed classes. Keeps your codebase on supported JDK versions.
- Security vulnerability remediation — Automatic dependency upgrades for known CVEs. Apply across all repositories simultaneously. Generate compliance evidence.
- JUnit 4 → JUnit 5 — Migrate test suites without manual rewriting. Keeps test coverage intact during modernisation.
- Logging framework migration — Standardise on a single logging framework across all services. Critical for centralised log aggregation and SIEM integration.
- Static analysis fixes — Automatically resolve SonarQube/Checkstyle findings. Reduce security scan noise so real issues are visible.
Implementation Strategy: How to Roll Out OpenRewrite
Phased Rollout for Enterprise Adoption
- Pilot with low-risk services — Pick 3-5 non-critical services. Run the RestClient migration recipe. Review the diffs. Run tests. Deploy. Build confidence.
- Integrate into CI/CD — Add OpenRewrite as a build plugin (Maven/Gradle). Run recipes in "dry-run" mode to detect drift — flag code that could be modernised but hasn't been.
- Batch execution across repositories — Once proven on pilot services, apply across all services. Use batch PR creation with automated test execution. Engineering leads review and approve per-service.
- Custom recipes for your patterns — Write organisation-specific recipes for your internal frameworks, deprecated utility classes, or API version migrations. These become reusable assets.
- Continuous modernisation — Keep OpenRewrite in your pipeline. As new Spring versions release, apply upgrade recipes continuously rather than accumulating years of technical debt.
AI Platform Assessment
Get a 2-3 week infrastructure audit with a concrete roadmap. No big-consultancy overhead.
Book Your Free Assessment →The Kotlin Connection
OpenRewrite also supports Kotlin — relevant for enterprises adopting Kotlin alongside Java (which is increasingly common given Kotlin's full backward compatibility with Java bytecode and libraries). The same recipe-driven approach applies: migrate Java patterns to Kotlin idioms, update deprecated Kotlin APIs, and modernise across mixed-language codebases.
For enterprises evaluating Kotlin adoption: OpenRewrite can automate the incremental conversion from Java to Kotlin, file by file, without requiring a big-bang rewrite. This makes Kotlin adoption a continuous, low-risk process rather than a project with a deadline.
Technical Debt Is a Compliance Risk
The real insight here isn't about RestClient specifically — it's about the relationship between technical debt and regulatory compliance. Every deprecated API in your codebase is a future security patch that won't apply cleanly. Every unsupported framework version is a CVE you can't remediate quickly. Under DORA and CRA, the speed at which you can remediate vulnerabilities is a regulatory requirement, not just a best practice.
OpenRewrite turns "modernise the codebase" from a multi-quarter project into a continuous, automated discipline. That's not just good engineering — it's a compliance capability.
Need Help Modernising Your Enterprise Java Estate?
We help regulated enterprises plan and execute large-scale Java modernisation — from Spring Boot upgrades to REST API migration to JDK version alignment. Automated, auditable, and aligned with DORA and CRA requirements. Start with a free assessment.
Related Solution
Navigating AI adoption in a regulated environment? Our readiness assessment maps infrastructure, governance, and compliance gaps in 2-3 weeks.
Explore AI Readiness for Regulated Enterprises →