Modernizing a legacy Java codebase

Case study in full

Example scenario

Stack profile: java-spring-boot-4-hexagonalJ · Example scenario with typical orders of magnitude.

A grown Spring project runs on an old Java and framework version. Dependencies have piled up over years, part of the test suite is red or skipped, and the migration kept being postponed because nobody could break it into small steps. That is exactly what the run takes over: target level into the ticket, plan into slices, one commit per slice.

What stays with your team: Your team sets the target level. You keep the review of every slice, the approval of critical dependency changes and the merge.

What you need

• A repository with a build configuration (Gradle or Maven) and a runnable test suite.
• A stack profile naming the target version and architecture conventions.
• Guardrails with the project's binding conventions.
• An approved ticket backlog for the first run.

How the run works

1. The ticket in the tracker describes the target level per module.
2. The plan breaks the migration into ordered, individually checkable slices.
3. Each slice changes one bounded portion: a dependency, an API adjustment or a test fix.
4. Per slice, compilation, the affected tests and static analysis run.
5. The result arrives as a pull request in your repository; you review and merge.

What you get

• Changed files and dependencies per slice, readable in the commit history.
• Test results and gate status documented per slice.
• One pull request per slice or bundled, referencing the ticket.
• Open points become tickets of their own in the backlog instead of quietly disappearing.

Key figures

What stayed open

Two older test classes do not yet cover the new code path; they are a ticket in the backlog.