Customize Copilot Modernization Tasks

Key Takeaways

In this episode, I show how you can customize GitHub Copilot modernization tasks in IntelliJ. So, Copilot works with your constraints, not against them. When Copilot modernizes a Java application, it doesn't just change code. It creates explicit modernization tasks, and those tasks are fully editable. That's the difference between automation and developer-controlled modernization. Copilot analyzes the project and proposes a set of modernization tasks. Think of these as a first draft, not a final decision. Now, we have something tangible, a task list that describes what will change, why, and in which order. Real teams always have constraints. Here, I'm explicitly telling Copilot what not to do. Instead of one risky step, I break this into smaller, reviewable tasks. You can also add your own requirements, just like you would in a real backlog. This task list now reflects our reality, not a generic upgrade path. Copilot adapts to the constraints instead of ignoring them. Tasks are applied one at a time. Nothing happens without review. When teams modernize Java applications, the real risk isn't the tooling. The risk is making changes you didn't intend to make. That's why GitHub Copilot modernization is built around explicit tasks, not automatic rewrites. In this screencast you just saw, I generated a modernization task list, customized it, and deliberately excluded the Java and Spring upgrades. Instead, I ran a regression and deployment safeguard task to validate the current state of the application. And the most important result is no files were changed, and that's the correct outcome. Project built successfully, deployment scripts are untouched, nothing about the runtime or infrastructure was modified. Copilot also surfaced two important facts. First, there's a failing test, but it's a pre-existing issue, unrelated to modernization. Mockito cannot mock a final class from the AWS SDK. Copilot correctly identifies the cause and explains the proper fix without trying to guess or to patch it automatically. That's exactly what you want from a modernization tool. Second, Copilot identifies known CVEs in the here you Spring versions. But because we explicitly excluded the Java and Spring upgrade, Copilot also explains that these vulnerabilities cannot be fixed within the current constraints. Again, no silent changes, no unsafe assumptions. This is what customizing modernization tasks really means. You tell Copilot what is allowed, what is blocked, and what must be verified, and Copilot operates entirely within those boundaries. Modernization isn't always about making changes. Sometimes it's about proving that now's not the right moment, and having the confidence to move forward with that knowledge. In the next episode, we'll take the next step and look at how to unlock a sequence higher impact modernization tasks once the prerequisites are met. But it always starts here, with clarity, constraints, and developer control. Like and subscribe to not miss the next episodes, and check out GitHub Copilot modernization in your IDE of choice.