windows-11-arm Runners Move to Visual Studio 2026

GitHub is moving windows-11-arm runners to Visual Studio 2026 by default, and the switch may break workflows that still depend on Visual Studio 2022, so your windows-11-arm runners need testing now. On August 20, 2026, GitHub made the Windows 11 arm64 VS2026 image generally available and scheduled the default migration to start September 21. That gives DevOps teams a short window to test before the toolchain changes underneath them. At Van Data Team, we help teams get ahead of migrations like this.

Key Takeaways

• On August 20, 2026, GitHub made the Windows 11 arm64 image with Visual Studio 2026 generally available under the label windows-11-vs2026-arm.
• GitHub will gradually move the default windows-11-arm image to Visual Studio 2026 starting September 21, 2026, with completion by September 30.
• The change may break workflows that depend on Visual Studio 2022, so C++, .NET, and native ARM64 pipelines are the most exposed.
• You can test the new toolchain now by setting runs-on to windows-11-vs2026-arm, before the default flips.
• Van Data Team's recommendation: test this week, fix what breaks, and decide before September 21 whether you're moving to VS2026 or need a pinned alternative.

What Did GitHub Announce?

GitHub announced that Visual Studio 2026 is now the going-forward toolchain for Windows ARM64 runners, with a firm date for the default to change.

Reported fact: On August 20, 2026, GitHub made the Windows 11 arm64 VS2026 image generally available on standard and larger GitHub-hosted runners. You use it by setting runs-on: windows-11-vs2026-arm in your workflow. That part is opt-in, and available today.

The bigger change is the default. GitHub will gradually update the windows-11-arm image to use Visual Studio 2026 by default, beginning September 21, 2026, and completing by September 30. In other words, if your workflow uses windows-11-arm, the toolchain under it is going to change automatically during that window, whether you touch the workflow or not.

GitHub is direct about the risk: moving to Visual Studio 2026 may break workflows that depend on Visual Studio 2022. It's part of a broader push, the hosted Windows images have been moving to VS2026 across the board, so this is the ARM64 piece of a wider shift, not a one-off.

Which windows-11-arm Runners Are Affected?

The windows-11-arm runners most affected are the ones whose builds quietly assume Visual Studio 2022, even if the workflow file never says so.

Van Data Team analysis: A toolchain upgrade isn't neutral. Between VS2022 and VS2026, compiler versions change, SDK and toolset paths can move, and default behaviors shift. A build that hard-codes a path, pins a compiler version, or relies on a VS2022-specific quirk is exactly the kind of thing that passes today and fails on September 22.

The highest-risk pipelines share a few traits:

• Native C++ on ARM64: compiler and toolset changes hit native builds first, and prebuilt binaries can break for downstream consumers.
• .NET with specific SDK expectations: if a job assumes a particular MSBuild or SDK layout, a new image can move it.
• Anything with hard-coded VS paths: a script that points at a VS2022 install directory won't find it after the switch.
• Long, rarely-touched workflows: the pipeline nobody has edited in a year is the one most likely to assume the old world.

If none of that describes you, the migration may be a non-event. If some of it does, the next few weeks matter.

What Actually Breaks in a VS2026 Migration?

Most breakages fall into a handful of predictable buckets. Knowing them turns a vague fear into a checklist you can work through.

• Compiler version drift. VS2026 ships a newer MSVC. Code that relied on VS2022 compiler behavior, or pinned a specific compiler version, can warn, error, or subtly change output. The fix is to rebuild, run your tests, and update version checks.
• Moved install paths. A script that hard-codes a VS2022 install directory won't find it after the switch. The fix is to use a tool like vswhere or the standard developer command prompt instead of a fixed path.
• SDK and toolset defaults. A new image can change the default Windows SDK or MSBuild layout. The fix is to set the SDK and toolset explicitly, so the image can't silently pick a different one.
• Prebuilt native binaries. If you publish ARM64 prebuilds, a compiler change can break them for downstream consumers even when your own build passes. The fix is to rebuild, republish, and version your artifacts.
• Stale build caches. A cache keyed on the old toolchain can serve outdated artifacts. The fix is to bust the cache key when the toolchain changes.

None of these are exotic. They're the ordinary friction of a toolchain upgrade, and each one is far easier to fix in a test branch than in a red pipeline.

The pattern is always the same: don't assume the environment, declare it. A workflow that names its SDK, toolset, and paths explicitly barely notices a migration. One that inherits them from the image feels every change.

How Do You Test windows-11-arm Runners Early?

Test by pointing your workflow at the new image now, so you find breakage on your schedule instead of GitHub's.

The mechanism is simple. Change runs-on: windows-11-arm to runs-on: windows-11-vs2026-arm in a branch, and run your real build and test jobs against it. You're not committing to the switch; you're previewing it.

If the build passes on windows-11-vs2026-arm, you're in good shape, and the automatic migration becomes a formality. If it fails, you've just found the problem with weeks to fix it, instead of during an incident. This is the same shift-left instinct we bring to catching a query-plan regression before it ships: test the change on your terms, early.

Should You Pin VS2022 or Move to VS2026?

For most teams, moving to VS2026 is the right call, and pinning is a temporary escape hatch, not a strategy.

Here's the honest trade-off. Moving forward means doing the migration work now, on your schedule, and staying on the toolchain GitHub actively maintains. Pinning to VS2022 buys time, but it's borrowed. The default is moving, the old image won't be maintained forever, and every month you wait is drift you pay back later.

So sort your pipelines:

• Move now if the workflow is active, the fixes are small, and nothing hard-blocks VS2026. This is most pipelines.
• Move soon if it needs real work but has no reason it can't run on VS2026 eventually. Schedule it, don't skip it.
• Pin deliberately only if a genuine dependency requires VS2022 today. Then treat the pin as a ticket with a deadline, not a permanent state.

The mistake is drifting into pinning by default because testing felt like effort. That's how a one-week task becomes a year-long liability. The toolchain will keep moving. The only question is whether you move with it on purpose or get moved by surprise.

Whatever you choose, write it down per pipeline. A decision you recorded is one you can revisit. A decision you made by not deciding is one that ambushes you later.

What Should You Do Before September 21?

Before September 21, run a short migration drill: test on the new image, fix or pin what breaks, and confirm your decision in writing.

The work is bounded, and it beats a surprise. Here's the checklist:

• Test now: run your ARM64 build and test jobs on windows-11-vs2026-arm in a branch.
• Triage failures: separate real incompatibilities from flaky tests, and log each one.
• Fix forward where you can: update hard-coded VS paths, compiler pins, and SDK assumptions for VS2026.
• Decide on the holdouts: for anything that genuinely needs VS2022, plan a pinned or versioned alternative and confirm it in GitHub's docs before September 30.
• Communicate the date: make sure every team that owns an ARM64 pipeline knows the default flips between September 21 and 30.
• Keep a rollback plan: know how you'd revert or route around a failure fast if a build breaks in production.

Speed and containers make this easier to rehearse, and the same build-hygiene mindset shows up in our guide to optimizing Docker image build times: a fast, repeatable pipeline is one you can test a migration against without dreading the wait.

One more habit pays off here: run the drill against your real workload, not a toy build. A migration passes on a hello-world job and still fails on the pipeline that actually matters, because the risk lives in your specific dependencies, not in the compiler alone.

So point the branch at the job that builds your real artifacts, with your real cache and your real matrix. If that passes on windows-11-vs2026-arm, you have earned your confidence. If it fails, you have found the exact thing to fix, with weeks to spare.

What If windows-11-arm Runners Break During the Rollout?

If a build breaks during the rollout, treat it like any production incident: contain it fast, then fix the root cause, rather than scrambling live.

Van Data Team analysis: The gradual rollout, from September 21 to 30, is both a risk and a gift. It's a risk because the change can reach your runners at a time you didn't pick. It's a gift because it's not instant, so a team that has tested ahead can respond calmly instead of firefighting.

The safe posture is to have your answer ready before the window opens. Know which of your windows-11-arm runners you rely on, know which ones you've tested on VS2026, and know your fallback for the ones you haven't.

A migration you rehearsed is an inconvenience. A migration you ignored is an outage. For the operational side of responding fast when something does break, our incident response playbook covers the same containment discipline.

How Van Data Team Helps

Van Data Team treats a runner migration as a small, testable change with a hard deadline, not a fire drill. We start by finding every ARM64 pipeline you run and sorting them by risk.

Then we test each one on windows-11-vs2026-arm, fix the VS2026 incompatibilities, and set a clear plan for any workflow that needs a pinned alternative, all before the September window. If you want help, our CI/CD and platform services can run the migration drill, fix the breakage, and hand you a pipeline that's ready for the default switch. The goal is a rollout you barely notice, because you did the work in August, not on September 22.

Test Your windows-11-arm Runners Now, Not During an Incident

The windows-11-arm migration to Visual Studio 2026 is straightforward to survive, but only if you test before the default changes on September 21.

GitHub gave you the tools and the runway: a GA image you can target today, a clear date, and honest warning that VS2022 workflows may break. The teams that come through this cleanly are the ones that treat the next few weeks as a testing window, not a countdown to a surprise.

It's worth stepping back, too. This won't be the last toolchain that moves under your pipelines. The teams that handle it well aren't lucky; they've made their builds declare their environment instead of inheriting it, so the next migration is a test run, not a fire. Treating this one as practice for that habit is the real win, well beyond the September date on the calendar.

There's no real downside to testing early. If your build passes on the new image, you've confirmed the migration is safe and you can move on with confidence. If it doesn't, you've bought the most valuable thing in any migration: time to fix it before it's urgent, on a calm branch instead of a broken pipeline.

The move is small. Point one branch at windows-11-vs2026-arm, run your real jobs, and fix what breaks. Do that this week, and the automatic migration becomes a non-event. Explore more CI/CD and platform guidance from Van Data Team, or use the checklist above to get your ARM64 pipelines ready before September.