GitHub Copilot Upgrade Agent Adds .NET Arm64 Migration for Windows and Other Platforms

The pitch is simple. Arm64 may lower compute costs and make infrastructure more efficient, but Microsoft gives no figures for either. The hard part is finding what stands between your codebase and a working Arm64 build. The agent is meant to find that out for you. Think of it as a very diligent intern who reads every .csproj file and then asks for a code review.

Why Arm64 migration is rarely a one-line change​

Flipping a build target is the easy bit. Microsoft's post lists the usual blockers:

• Code and build settings tied to one architecture.
• Native dependencies that ship no Arm64 binaries.
• Packages or libraries that need Arm64-compatible versions.
• Platform assumptions spread across several projects.
• Configuration that targets only x64 or x86.

The post says an x64 build setting is easy to spot. A package that quietly depends on a native library with no Arm64 binary takes more digging. Pure managed code usually carries over, but a transitive native asset can break a build you thought was done. That is general .NET experience, not a claim from the announcement.

What the agent does​

Microsoft says the agent can:

1. Analyze the application and its dependencies for Arm64 compatibility.
2. Identify architecture-specific assumptions and unsupported components.
3. Create a migration plan based on the codebase.
4. Help update code, dependencies and project configuration.
5. Build the migrated components for Windows Arm64. When matching hardware or CI runners are available, it can also run tests to help validate runtime behavior.

You can review the plan and the proposed changes as the agent works, and it brings you in when a step needs your input. These are Microsoft's claims about the product. The post gives no detection rates, success rates or benchmarks, so treat it as an assistant and not a guarantee.

The broader Microsoft Learn scenario documentation adds technical detail. The agent targets the ARM64 runtime identifiers win-arm64, linux-arm64, linux-musl-arm64 and osx-arm64, fixes x86 and x64 assumptions, resolves missing ARM64 native NuGet assets, and guards x86 hardware intrinsics. That documentation covers more targets than the Windows-focused blog post. For Windows work, win-arm64 is the identifier that matters.

A passing build is not proof​

Microsoft is clear that a successful build is an important checkpoint, not the finish line. Runtime behavior still has to be validated on Windows Arm64. In practice, that means real Arm64 hardware or an Arm64 CI runner. Native interop, P/Invoke calls, third-party drivers and anything that loads a native DLL at runtime are the usual places where a clean compile hides a crash.

The scenario also covers portability and correctness only. Microsoft's docs also suggest ARM64 migration as follow-on work after a .NET version upgrade. Performance tuning for Arm64 is out of scope. Once the app is validated, Microsoft suggests measuring performance in your own environment and then deciding whether tuning is worthwhile.

How to get started​

The blog's sequence is:

1. Install GitHub Copilot upgrade in your preferred development environment.
2. Select the upgrade agent from the agent picker and say you want to migrate your .NET app to Windows Arm64.
3. Choose the .NET Arm64 migration scenario when prompted.
4. Review the assessment and the proposed migration plan.
5. Let the agent make changes, reviewing each update and completing any steps that need your input.
6. Validate runtime behavior on Windows Arm64 hardware or CI runners.

Setup differs by environment, according to Microsoft Learn's install guidance:

• Visual Studio: You need Windows and Visual Studio 2026, or Visual Studio 2022 version 17.14.17 or later. You also need the .NET desktop development workload with the GitHub Copilot and GitHub Copilot app modernization optional components enabled. You then need a GitHub account with Copilot access. Right-click a project and choose Modernize, or type @Modernize in Copilot Chat.
• Visual Studio Code: You need the GitHub Copilot extension and a Copilot subscription. In VS Code, open the GitHub Copilot Chat panel and type @upgrade. You install the "GitHub Copilot upgrade" extension from the Extensions view (Ctrl+Shift+X).
• GitHub Copilot CLI: Add the marketplace with /plugin marketplace add microsoft/upgrade-agent-plugins, then install the plugin with /plugin install upgrade-agent@upgrade-agent-plugins.
• GitHub Copilot app: Select Upgrade in the agent picker.

What the agent leaves behind in your repo​

Microsoft Learn describes the general upgrade workflow as three stages: assessment, planning and execution. Each stage writes Markdown files under .github/upgrades/{scenarioId}. The documented files include assessment.md, upgrade-options.md, plan.md and tasks.md. You can edit them before moving on, and the docs recommend committing the folder to your branch so teammates can follow progress.

The docs say Copilot offers to create a branch when you are in a Git repository, and it commits each portion of the work. That makes review manageable and lets you roll back or cherry-pick changes. These details come from the general upgrade-agent documentation. I have not verified that the Arm64 scenario produces identical outputs.

Limits to know before you start​

Microsoft's FAQ lists several constraints that apply to the agent in general:

• A local Git repository is required.
• Upgrade suggestions aren't guaranteed to follow best practices.
• An internet connection and GitHub Copilot cloud infrastructure are required, so there is no offline use.
• A Copilot subscription is required. The FAQ lists Free (starting with Visual Studio 2026 version 18.1), Pro, Pro+, Business and Enterprise. Corrections you make during an upgrade are not remembered for future upgrades.

The blog post does not give a rollout schedule, a minimum .NET version, or a project-type matrix specific to this scenario. I won't guess at those.

Analysis: who benefits, and the caveats​

Teams that need Windows on Arm support, whether for Copilot+ PC-style devices or for cheaper Arm cloud hardware, get a structured way to take inventory. The assessment step may be the most useful part. Knowing which of your 40 projects hides a native dependency is worth a lot, even if you write every fix yourself.

There are fair reasons for caution:

• The announcement comes from Microsoft and reports no independent results.
• AI-generated changes still need human review, especially in code that touches native libraries or hardware intrinsics.
• Cost and efficiency benefits depend on your workload, and nothing in the post demonstrates them.
• The Copilot subscription requirement adds cost, which has drawn criticism before. DevClass reported that developers pushed back on the Copilot-based modernization tooling that replaced the old free upgrade assistant.

A sensible approach is to run the assessment on a branch, read assessment.md and plan.md critically, and let the agent make the changes. Then run your full test suite on actual Arm64 hardware or a runner. If the tests pass, measure performance before deciding whether tuning is worth the effort.