Customize Copilot Modernization Tasks
Sandra Ahlgrimm explains how to customize GitHub Copilot’s modernization task lists so teams can modernize legacy Java apps safely: set constraints, split risky upgrades into smaller reviewable steps, validate the current state first, and ensure Copilot surfaces CVEs without making silent changes.
Overview
This episode focuses on tailoring GitHub Copilot’s modernization tasks to match real-world engineering constraints when upgrading legacy Java applications.
How Copilot’s modernization task list should be used
- GitHub Copilot generates an editable modernization task list.
- The task list is positioned as a first draft to review and refine, not an automatic final plan.
Setting explicit constraints (what Copilot should not do)
- The workflow includes telling Copilot what NOT to change.
- Example constraint called out: exclude Java and Spring upgrades when they’re too risky or out of scope.
Breaking large upgrades into smaller, reviewable work
- Large modernization efforts can be split into smaller tasks.
- The goal is to make changes reviewable and aligned with the team’s risk tolerance.
Adding custom requirements like a real backlog
- The task list can be extended with custom requirements, similar to how teams manage an engineering backlog.
Handling pre-existing issues without silent fixes
- Copilot is expected to respect the current state and avoid silently patching unrelated problems.
- Example mentioned: a failing Mockito test should be surfaced/handled explicitly rather than quietly “fixed” as a side effect.
Surfacing security issues (CVEs) while respecting constraints
- Copilot can surface CVEs during modernization.
- The emphasis is on no silent changes and no unsafe assumptions, even when vulnerabilities are detected.
Series context
- Episode 5 of the Modernize Java Apps with AI series.
- Playlist: https://www.youtube.com/playlist?list=PLlrxD0HtieHhaBJWlcxGd-kTDikSD4xyD
- GitHub Copilot Modernization extension: https://aka.ms/GHCPMod-Java