OpenRewrite

Software Modernization with OpenRewrite

Automating Large-Scale Framework Migrations

Introduction

We are a small software consulting company based in Vietnam, currently focusing heavily on software modernization.
Most of our customers operate in the social security domain, where applications tend to be large, long-lived, and business-critical.

One of the key concepts we use to modernize software efficiently is OpenRewrite.
Today, I’ll show how we use it in practice.

If you like what you see: there are several people from Gepardec here today who know OpenRewrite inside out—feel free to talk to them afterward.

The Reality of Legacy Applications

Most real-world applications rely on a wide range of frameworks and libraries.
Especially in older systems, we often see:

• Java EE

• Spring 3

• JUnit 4

• Quarkus 2

• Log4j 1

• many other outdated dependencies

Over time, these frameworks evolve. Examples:

• Java EE → Jakarta EE

• JUnit 4 → JUnit 5

• major Quarkus upgrades

These are usually major upgrades, not minor version bumps.
They involve many manual code changes, which raises several challenges:

• They are time-consuming

• They are error-prone

• They are not fun

• They don’t scale across teams or applications

Why Manual Migration Doesn’t Scale

Jakarta EE as an Example

Jakarta EE 9 introduced a massive change:

• javax.* → jakarta.*

But not everything changed.
For example:

• javax.naming stayed javax.naming

On top of that, dependencies complicate things further.

You might update:

• the Servlet API
  …but still rely on:

• Hibernate, which itself depends on older APIs

So you must migrate transitive dependencies as well, not just the ones you declare directly.

Organizational Problems

Manual migrations cause additional pain:

• Developers continue working in parallel → huge merge conflicts

• “Stop-the-world” migrations freeze development → business impact

• Large organizations have many applications that all need the same changes

• The same transformations are repeated again and again

Why OpenRewrite Exists

OpenRewrite originated at Netflix.

Netflix runs thousands of microservices.
They asked themselves:

“Why do we have to perform the same migration manually for every service?”

Their answer:

• Treat migrations as code

• Make them reproducible

• Make them automatable

This led to the concept of recipes.

What Is a Recipe?

A recipe defines a set of code transformations.

There are two main types:

1. Composite recipes

   • YAML-based

   • Combine multiple transformations

2. Custom recipes

   • Written in Java

   • Used for application-specific logic

Why Not Just Use Search & Replace or AI?

Text Replacement (IDE / Regex)

• Code meaning is not just text

• Types and semantics matter

• Regex cannot safely express semantic intent

Large Language Models (AI)

• Not deterministic

• Hard to trace why something changed

• Risky for regulated environments

• Often not allowed due to data residency constraints

That said: LLMs and OpenRewrite can complement each other, for example by recommending recipes.

What OpenRewrite Supports

OpenRewrite works across many formats:

• Java

• XML

• YAML

• JSON

• Properties

• Groovy

• Maven & Gradle metadata

Example: Jakarta EE Migration Recipe

A standard Jakarta EE 11 recipe:

• Updates Java imports (javax → jakarta)

• Updates Maven dependencies

• Updates XML configuration files (e.g. beans.xml)

Execution is straightforward via the Rewrite Maven Plugin.

Dry Run vs Run

• Run → modifies code directly

• Dry Run → generates a patch file

We usually prefer dry runs, because IDEs like IntelliJ can review and apply patches safely.

Extending Recipes with Composite YAML

Sometimes an official recipe doesn’t cover everything.

Example:

• A dependency didn’t migrate automatically

Solution:

• Add an additional recipe to a composite YAML

• Define:

  • old groupId / artifactId

  • new groupId / artifactId

  • version strategy (latestVersion, etc.)

Now one execution handles everything consistently.

Beyond Code Changes: Impact Analysis

OpenRewrite is also useful before a migration.

Data Table Recipes

These generate CSV files describing your codebase:

• language composition

• files per package

• lines of code

• dependency usage

This helps answer questions like:

• How big is this migration really?

• Which parts of the codebase are affected?

The Transformer Approach to Migration

Instead of stopping development:

• Write a migration recipe

• Let development continue

• Regularly re-run the recipe

• Adjust the recipe, not the code

At the end:

• Apply the recipe once

• Perform the migration cleanly

This avoids merge hell and keeps progress measurable.

Preconditions for Successful Automation

Before using OpenRewrite effectively, you need:

• Explicit dependencies (no hidden transitive reliance)

• Good test coverage

• Clean structure (remove dead code, cycles, unused modules)

Automation magnifies quality — good or bad.

Migration in Iterative Phases

We slice migrations into cycles:

1. Compile

2. Unit tests

3. Deployment

4. Integration tests

Each failure:

• teaches us something

• gets encoded into the recipe

Repeat until green.

Writing Custom Recipes (Advanced)

OpenRewrite builds a Lossless Semantic Tree (LST):

• Preserves formatting & comments

• Includes full type information

• Enables precise transformations

Recipes use the Visitor Pattern:

• Traverse the AST/LST

• Apply guarded transformations

• Remain deterministic

We demonstrated:

• writing a custom Java recipe

• testing it with before/after assertions

• ensuring idempotency and type correctness

Recipe Quality Criteria

A good recipe must be:

• Type-safe

• Idempotent (safe to run multiple times)

• Atomic (small, focused transformations)

Sharing Recipes

Two common patterns:

1. Internal toolbox

   • Shared artifact with company-specific recipes

2. Library-driven migrations

   • Frameworks (e.g. Quarkus) ship recipes

   • Example: mvn quarkus:update

Gepardec Auto Update Service

At Gepardec, we combine:

• Renovate Bot (detects new versions)

• OpenRewrite (performs migrations)

• CI pipelines

• Dev containers for manual fixes

Result:

• Automated pull requests

• Verified by tests

• Minimal manual effort

• Continuous modernization

Closing & Q&A

OpenRewrite is:

• Open source

• Actively maintained

• Supports Java LTS versions (including Java 21)

• Backed by a strong community

Slides, examples, and resources are available via the QR code provided.

Thank you for your attention.