Windows Arm64 Migration for .NET With GitHub Copilot Upgrade

Microsoft’s November 5, 2026 .NET Blog post describes Windows Arm64 migration in the GitHub Copilot upgrade agent. The agent can assess a .NET solution built for Windows x64 or x86, identify blockers, draft a plan, and help change code, dependencies, and project settings. Runtime testing on Windows Arm64 is still part of the migration.

What did .NET developers do before the upgrade agent?

A migration usually starts with an inventory. Find the projects and build steps that assume x64 or x86. Check references to native libraries, installers, and other components that run outside managed .NET code. Then restore packages and publish a Windows Arm64 build to see which assumptions survive.

The difficult cases are often transitive. The project may reference a managed NuGet package that loads a native binary at runtime. The application can compile even if that binary is unavailable for Arm64. The failure appears when a user opens the feature that triggers the load.

The upgrade agent helps organize those checks and propose changes in a single workflow. Microsoft describes assessment, planning, implementation, build validation, and runtime tests when compatible hardware or runners are available. Its November post says the scenario is available, without giving a separate GA date for it. Installation requirements depend on the development environment. Microsoft’s announcement · Installation requirements

Manual versus agent-assisted Arm64 migration

Area	Manual workflow	Agent-assisted workflow	What the team reviews
Assessment	Search project files and dependency graphs	The agent assesses the solution and identifies blockers	Native or deployment dependencies outside the repository.
Planning	Build a migration checklist	The agent proposes a codebase-specific plan	Which projects move together and who owns unresolved blockers.
Changes	Edit target settings, packages, and code	The agent helps prepare changes	Whether upgrades and architectural assumptions are justified.
Build	Publish for Windows Arm64 and investigate errors	The agent can help build migrated components	Whether the produced artifact matches packaging and deployment requirements.
Runtime	Run workflows on an Arm64 machine or runner	The agent can help run tests when that environment is available	Which native and operational paths were actually exercised.

Windows Arm64 migration checkpoints.

How do build settings and dependencies affect the move?

A runtime identifier, or RID, tells .NET which target platform assets to resolve. For current .NET projects, win-arm64 identifies Windows on Arm64. Review the runtime target alongside project architecture settings and the way your application ships. A framework-dependent publish needs the correct runtime on the target machine. A self-contained publish carries the runtime for its chosen target.

NuGet compatibility has two sides: the managed target framework and the runtime-specific assets. If a package relies on a native database driver, graphics library, or vendor SDK, check what the package or vendor actually supplies. A managed wrapper may support your framework while lacking a suitable native binary. Ask the agent to identify likely blockers, then confirm them against package contents or vendor documentation. Microsoft RID catalog

What does a practical migration look like?

Take a Windows service that processes uploaded images. The service compiles against a managed interface and calls a native image decoder when a file arrives. Before changing the target, record a baseline with representative inputs on the current deployment. Ask the upgrade agent to identify architecture-specific build settings, the package that ships the decoder, and any hardcoded file paths or installer assumptions.

Review the plan before applying it. If a compatible decoder package exists, evaluate its API and output changes before approving the upgrade. If it is missing, the team has to decide whether to replace the dependency, isolate the affected component, or defer that workload. Automation can identify a missing dependency, but replacement is an engineering decision.

After building, run the actual decode, service startup and restart, and a failure case on a Windows Arm64 machine or runner. If the installer registers a service or ships architecture-specific files, test a clean installation as well. Record the process architecture and package versions with the test results. Otherwise, a successful run under a different architecture can give you confidence in the wrong artifact.

How should teams review the result?

Use a branch and keep each dependency or platform change reviewable. Check affected CI jobs and confirm the deployment process selects the right output for each platform. If x64 customers remain supported, run their existing tests as well. The upgrade agent’s scenario focuses on compatibility. Measure throughput, latency, and resource use separately on representative hardware before drawing performance or cost conclusions.

ASP.NET PB’s IIS deployment guide covers the deployment checks that still matter for web applications after a build succeeds.

Frequently asked questions

Can the agent make an unsupported native library work on Arm64?

It can help locate the blocker and suggest changes. You still need a vendor-supported Arm64 binary, a compatible replacement, or a different architecture for that component.

Is a successful build enough?

No. Exercise the application paths that load native libraries, start processes, or rely on operating-system integration. Those failures can appear only at runtime.

Will this change the application’s performance?

Microsoft describes a compatibility workflow. Measure performance on the intended hardware before committing to an infrastructure change.

Start with one project that has a known test suite. A small migration with an explicit native dependency checklist will tell you more about feasibility than a solution-wide build result on its own.