The primary obstacle to modernizing legacy applications is the lack of confidence in the ultimate cost and time to get to a successful outcome. While tools can automate the mechanical aspects of an upgrade, the fundamental question remains: “how can you be sure the upgrade hasn’t introduced regressions?” This concern is particularly acute for older applications that often have an insufficient level of existing regression tests, making it difficult to verify that functionality has been preserved post-upgrade.
The challenge is not confined to a single application but extends across an enterprise’s entire codebase. A solution must be scalable to handle an entire “estate of applications” to be effective.
This dilemma often leads to inaction, leaving valuable systems running on outdated and unsupported stacks. But what if you could automate the refactoring and the confidence check? Our CTO and Co-founder, Peter Schrammel’s latest video tutorial, combining Moderne’s automated refactoring with Diffblue’s AI-powered test generation, did just that, and the process revealed some important insights about upgrading software at scale.
A Two-Part Solution for Verified Refactoring
Two distinct technologies, when combined, can address the challenge of confidence and scale in application modernization.
1. Moderne with OpenRewrite: Automated Refactoring
Moderne provides a SaaS platform and Command Line Interface (CLI) that leverages OpenRewrite recipes to perform complex, automated refactorings at high speed. The platform operates by first scanning a codebase to build an intermediate representation (LSTs), which then enables it to apply upgrade and refactoring recipes across the entire codebase efficiently.
2. Diffblue Cover: AI-Powered Test Generation
Diffblue Cover automatically writes unit tests for Java applications. It is available as a recipe within the Moderne ecosystem, allowing it to be integrated directly into the scaled refactoring process. The technology employs a high-speed reinforcement learning loop, generating a test candidate, assessing its effectiveness based on metrics like code coverage, and feeding that information back to predict a better test. The code is executed in an embedded sandbox to protect your development environment. This process runs at a rate of a thousand iterations per second, enabling it to scale to codebases with millions of lines of code.

The Three-Step Process for Confident Upgrades
The synergy between Moderne and Diffblue Cover facilitates a structured, verifiable upgrade process that can be applied to any refactoring task.
Case Study: Upgrading Spring Boot 2 to 3
Here are some key takeaways from our demo showcasing this process on the Spring Pet Clinic application.
1. You Can Automate Confidence Before You Even Touch the Code
Typically, an upgrade process starts with the upgrade itself, followed by a testing phase. Our approach inverts that risky process. The modernization begins not with the upgrade, but by tackling the primary source of anxiety: the unknown. The first, counterintuitive step is to define what “working” means before a single line of application code is changed.
Before the upgrade, we used the Diffblue Cover recipe within the Moderne platform or CLI to write unit tests for the application automatically. In this example, the application already had a respectable 81% test coverage. After running the Diffblue Cover recipe, that figure jumped to an exceptional 98%. This automated test generation created a comprehensive safety net, providing a verifiable baseline of the application’s correct behavior. This step is a game-changer because it provides the confidence needed to proceed with a major refactoring, turning a high-risk guess into a predictable, data-driven operation.

2. The most valuable test is the one that fails.
With the safety net in place, the next step is to run the Moderne recipe to upgrade the application. This isn’t a simple version change; the automated refactoring handles the migration from Java 11/Spring Boot 2 to Java 17/Spring Boot 3, and also includes an upgrade of JUnit from version 4 to 5. The automation completed successfully, but when the previously generated test suite is run, a test failed.
At first glance, a failed test appears to be a problem. In reality, it was the entire process working perfectly. The failure wasn’t a catastrophic error, but a subtle regression that would have been incredibly difficult for a human to spot. The root cause was a change in Spring Boot 3’s default content negotiation behavior. An endpoint that was expected to return a JSON document was now returning XML instead.
This highlights the core challenge of any major upgrade:
“But how can you be confident that nothing has been broken by the upgrade? You might be particularly worried about that when your legacy application doesn’t have a sufficient level of regression tests.”
The “failure” was the answer to that question. The AI-generated test caught a subtle breaking change introduced by the framework upgrade, proving the safety net was effective. The problem was identified, isolated and fixed in minutes, not discovered days or weeks later during a production incident.
3. Verified Refactoring Is a Strategy, Not a One-Off Trick
This isn’t a single project; it’s a new operational model.
The true power of this approach becomes clear when you look beyond a single application. This process is not a one-off trick but a scalable, repeatable strategy for enterprise-wide modernization. The pattern is simple, powerful, and concrete.
The combination of Moderne’s platform for applying recipes and Diffblue’s recipe for generating tests allows companies to apply this modernization pattern “at scale across your entire estate of applications.” It transforms modernization from a series of high-risk, bespoke projects into a manageable, continuous, and verifiable process.
Conclusion: Modernize Fearlessly
The key takeaway is that AI-powered automation isn’t about blindly changing code. It’s about building a verifiable system that gives you the confidence to make bold changes. By automating the safety net first, you fundamentally change the risk equation of software modernization, shifting the sentiment from “hoping nothing breaks” to the goal of “proving everything works.”