Microsoft has announced the general availability of GitHub Copilot modernization, an agentic toolchain that assesses, upgrades, and migrates application portfolios to Azure. The announcement landed on the Azure Updates feed this week, and it closes out a preview cycle that started earlier this year for the parts teams actually touch: the IDE experience for language and framework upgrades is now GA for .NET, Java, and C++, along with the migration scenarios for .NET and Java. The portfolio-level agent that drives the Modernize CLI is still in public preview.
Two layers, two jobs
The product is split deliberately. The modernization agent ships as a CLI aimed at architects and application owners. It reads a portfolio, produces assessments and migration plans across many applications at once, and can run batch framework upgrades. The IDE experience is where developers execute: migrating dependencies to Azure services, containerizing apps, generating infrastructure as code, and pushing the result to Azure.
That split matters because estate upgrades usually die in the assessment phase. Nobody wants to spend three months reading old web.config files before anyone writes a line of migration code. The agent’s batch mode handles the repetitive part: it detects the language from the first repository in a batch, builds an upgrade plan from your prompt or defaults to the latest LTS target, then applies the plan repo by repo and validates the build after each one. All repositories in a batch must use the same language, which is a sensible constraint given how differently a Java 8 to 21 jump plays out compared to a .NET Framework to .NET 10 port.
A typical run looks like this:
modernize upgrade "Java 21" --source .github/modernize/repos.jsonYou can point it at a folder, feed it a JSON config of repositories, or pass Git URLs directly. There is also a --delegate cloud flag that hands execution to Copilot’s cloud agents instead of running locally, which matters if you have more repos than laptops. When the batch finishes you get an aggregated report, and the intended flow is to review each repository’s diff and open pull requests with gh pr create.
What it actually migrates
The upgrade story is the headline, but the migration targets are where the Azure-specific value sits. The agent handles moves to Service Bus, Azure SQL, Redis, Key Vault, Application Insights, and Managed Identity, which covers the checklist most legacy .NET and Java apps need before they can run in the cloud without embedded credentials. Two adjacent capabilities round it out: scanning and fixing CVEs in NuGet dependencies, and structural rearchitecture such as monolith-to-microservices decomposition and module extraction.
Microsoft’s documentation is blunt about the human role: every recommendation is meant to be transparent, every change reviewable, every step validated. In practice that means the agent produces plans and patches, but nobody should be merging a portfolio-wide upgrade without eyeballing the diffs. Framework upgrades are exactly the kind of change where a plausible-looking patch can silently change behavior.
Licensing and availability
The modernization capabilities ride on GitHub Copilot plans: Pro, Pro+, Business, and Enterprise. The Copilot Cloud Agent path has the same plan requirements, and organization admins need to have the relevant Copilot policies enabled. If you receive Copilot through an organization and the CLI is missing, that policy toggle is the first thing to check.
Worth trying, with expectations set
Automated upgrade tooling has a mixed track record, so the smart entry point is the assessment mode, not the upgrade mode. Run the agent in assess mode across your portfolio first and read the output before letting it touch code. Batching same-language repos keeps failure domains small, and the batch workflow marks mismatched repositories as failed rather than guessing, so a bad repo does not poison the run.
The genuinely new part here is portfolio-level orchestration. IDE-assisted upgrades have existed for a while; what has been missing is a tool that can look at forty applications, tell you which ones are realistic upgrade candidates, generate the plans, and hand developers reviewable pull requests. Whether the generated upgrades hold up under real test suites is the question every team will answer differently, but the assessment-to-PR pipeline alone saves the survey work that usually stalls these projects. If you own a legacy estate on Azure, the preview-to-GA path is now clear enough to justify a pilot on your least critical tier.
Where pilots get stuck
A few failure modes show up consistently in agentic upgrade runs, and it is cheaper to plan for them than to discover them mid-batch. Repositories with large amounts of generated or vendored code confuse the assessment pass and produce plans that read well but patch badly, so exclude generated directories from scope up front. Build tooling drift is the second common snag: an agent upgrading a Java 8 project will happily produce code that assumes a Maven or Gradle plugin set the repo has never pulled. The build validation step catches this, but only if the repo’s build actually runs in your environment and not just the agent’s sandbox. The third is test coverage, or the lack of it. Batch validation can confirm a project compiles after an upgrade, which is a much weaker guarantee than the behavior staying the same. Repos with thin test suites are exactly the ones where a human should review the diff line by line, so sort your portfolio by coverage before you sort it by anything else. Start with the well-tested repos, learn what the agent’s diffs look like, and treat the untested legacy tier as a manual project regardless of what the tooling promises.