windows-11-arm switches to Visual Studio 2026 in early September 2026: 4 components disappear

Summary. GitHub said on 11 June 2026 that at the end of the public preview, "in early September", the existing windows-11-arm image label will migrate to the Visual Studio 2026 image. Reading the two live READMEs in actions/runner-images on 21 August 2026 shows what that swap actually does: Visual Studio Enterprise 2022 17.14.37516.0 is replaced by Visual Studio Enterprise 2026 18.7.11925.98, the install path moves from C:\Program Files\Microsoft Visual Studio\2022\Enterprise to ...\Microsoft Visual Studio\18\Enterprise, Windows SDK 10.0.19041.0 is dropped, and four component groups present today are absent from the replacement. GitHub named a fallback label when it did the same thing to x64 in June — windows-2022. For ARM64 it has named none. Runner rates fell by up to 39% on 1 January 2026 and a $0.002 per-minute Actions cloud platform charge sits on top, so the cost of a broken ARM matrix is now measured against a cheaper baseline, not a forgiving one.

What GitHub actually announced, and when

Three dated statements matter here, and all three come from GitHub.

On 14 May 2026 GitHub said it now owns and maintains the Arm64 runner images, taking them over from Arm Limited, LLC, and that windows-11-arm had "already transitioned to GitHub-managed builds and pipelines". The same post announced the x64 migration: windows-latest and windows-2025 would move to Visual Studio 2026 by default, rolled out between 8 and 15 June 2026, with a clear instruction for teams that wanted to stay put — "If you want to remain on VS 2022, update the runs-on: target in your YAML workflow file to windows-2022."

On 11 June 2026 GitHub published the ARM64 preview: a new image under the label windows-11-vs2026-arm, running in parallel with the existing one, and this sentence — "At the end of the public preview in early September, the existing windows-11-arm image label will migrate to the vs2026 image."

That post named no windows-11-vs2022-arm equivalent. The tracking issue in actions/runner-images, #14225, does not name one either. As of 21 August 2026 the GitHub Changelog index carried no entry dated 20 August, so the general-availability post that feed readers began circulating that day could not be confirmed against GitHub's own index at the time of writing. The migration date in GitHub's own words is still "early September".

What actually changes in the image

The two READMEs on main are the authoritative diff, and they disagree with the June announcement in a useful way. GitHub's 11 June table said the preview image carried Visual Studio Enterprise 2026 build 18.6.11822.322. The README on 21 August 2026 says 18.7.11925.98. The toolchain moved a full minor version during the preview, which is exactly the kind of drift a build that pins a VC toolset version will find.

Note the second row. The preview image is dated 14 July 2026; the image the label points at today is dated 9 August 2026. The candidate replacement is 26 days staler, which is why almost every tool on it sits one patch behind: Node 24.18.0 against 24.19.0, Python 3.13.14 against 3.13.15, Git 2.55.0.windows.2 against 2.55.0.windows.3, CMake 4.4.0 against 4.4.2, Gradle 9.6 against 9.7, PowerShell 7.6.3 against 7.6.4, Kotlin 2.4.0 against 2.4.10, Bicep 0.45.15 against 0.46.1. None of those individually breaks a build. Collectively they mean the September flip is not only a compiler change; it is also a step backwards on a dozen unrelated tools until the VS2026 image catches up on its build cadence.

The four component groups that are gone

This is the part the announcement does not cover, and it is the part that fails a pipeline at 03:00.

Every ARM32 component in the VS2022 image — the compiler toolset, the ATL headers, the Spectre-mitigated runtimes — is absent from the VS2026 image. A native project still emitting an arm (not arm64) configuration will not find a toolset after the flip. Nor will an MSIX or ClickOnce package that pins WindowsTargetPlatformVersion to 10.0.19041.0. Xamarin projects that had not yet moved to .NET MAUI lose their component entirely, and the MAUI workload itself jumps from 9.0.111.6930 to 10.0.20.7528, alongside .NET runtime packs that move from the 9.0 line to the 10.1 line. The VS2026 image installs Microsoft.NetCore.Component.Runtime.8.0 and Runtime.10.0; the 9.0 runtime component that the current image carries is not in its list.

The compensations are real but narrower than the deletions. The VS2026 image adds Microsoft.VisualStudio.Component.VC.14.44.17.14.ARM64 — the 17.14 MSVC ARM64 toolset — alongside the older 14.29 one, so a build that pins v143 has a path. It ships Android SDK 36.1.43.0 with NDK R27C against 35.0.78.0 with NDK R23C, and a newer Windows SDK component, 10.1.26100.8249 against 10.1.26100.7705. One more detail worth knowing if your workflow shells out to R: the current image annotates R 4.6.1 as "(x86_64, emulated)", and the VS2026 README carries no such annotation.

How to tell whether this is you

Four checks, none of which needs a test run.

Search your workflows for runs-on: windows-11-arm. That is the only label affected; windows-11-vs2026-arm and the x64 labels are not. Next, grep your project files for WindowsTargetPlatformVersion and look for 10.0.19041.0 — that SDK is not on the replacement. Third, grep for a <Platform>ARM</Platform> or an arm (not arm64) configuration in any .vcxproj; the toolset backing it does not exist on the new image. Fourth, look for vswhere calls or hardcoded paths containing \2022\Enterprise. The install directory changes to \18\Enterprise, and hardcoded paths are the most common way a Visual Studio major-version bump breaks a script that otherwise had nothing to do with the compiler.

The honest read on the risk: an ARM64 .NET build with no native ARM32 configuration and no SDK pin will almost certainly survive the flip untouched. A C++ or MAUI build with either of those will not.

What to do, and by when

Pin the label to windows-11-vs2026-arm in a branch and run your full matrix against it this week. That label is the same image the migration will deliver, so a green run there is a real result, not an approximation. If something fails, you have roughly two weeks of preview left to fix it or to raise it in actions/runner-images, which is where GitHub asked for preview feedback.

Do not assume a fallback label will appear. GitHub gave x64 users windows-2022 and said so plainly in the 14 May post; it has published no ARM equivalent. If your build genuinely cannot move off VS 2022 on ARM64, the realistic options are a self-hosted ARM64 runner or a custom image, and both need to be standing before September, not after. GitHub's May post noted it is expanding self-hosted support, including Windows, over the following 12 months, so the tooling is improving — but not on your timetable.

Cost changes the arithmetic slightly. GitHub cut GitHub-hosted runner prices by up to 39% on 1 January 2026 and introduced a $0.002 per-minute Actions cloud platform charge, which is already folded into the hosted rates. Public repositories stay free and GitHub Enterprise Server is unaffected. Running a duplicate ARM64 matrix leg against the preview label for two weeks is cheap insurance against a September morning spent bisecting a compiler change nobody scheduled.

What is still unknown

GitHub has not published a calendar date, only "early September". It has not said whether the migration is instant or staged — the x64 move took a week, and the macos-latest move took 30 days, so a staged rollout is plausible but unconfirmed. It has not said whether the VS2026 ARM image will be brought level with the current image's tool versions before the flip or after. And it has not addressed the ARM32 and SDK 19041 removals at all, which is why the READMEs, not the announcements, are the document to read.

India-specific considerations

Windows ARM64 CI matters disproportionately to Indian product teams shipping .NET MAUI and native Windows clients for global customers, where an ARM64 leg is often the newest and least-exercised part of the matrix. Two habits help. Keep the runner label in one place — a workflow-level env or a reusable workflow input — so a label change is one commit, not forty. And treat GitHub's image announcements as a monitored feed rather than something a developer notices: the ARM32 and SDK removals here appear only in a repository README, not in the changelog post, and nobody reads a README on a schedule.

FAQ

How eCorpIT can help

We run CI and release engineering for product teams shipping Windows, Android and iOS clients from India to global customers, which means image migrations like this land on us before they land on the client. Our engineers audit workflow matrices for pinned SDKs, hardcoded toolchain paths and unexercised architecture legs, then stage the change against the preview label so nothing flips unannounced. eCorpIT is CMMI Level 5, MSME certified and ISO 27001:2022 certified. If your ARM64 matrix has not been run against windows-11-vs2026-arm yet, talk to our engineering team.

For related reading, see our notes on GitHub Actions secret isolation and runner memory, self-hosted runner version enforcement, and GitHub Code Quality billing and audit changes.

References

1. New runner images in public preview — GitHub Changelog, 11 June 2026

1. GitHub Actions: Upcoming image migrations — GitHub Changelog, 14 May 2026

1. actions/runner-images issue #14225: Windows 11 Arm with Visual Studio 2026 public preview

1. Windows11-VS2026-Arm64-Readme.md, actions/runner-images main branch

1. Windows11-Arm64-Readme.md, actions/runner-images main branch

1. Update to GitHub Actions pricing — GitHub Changelog, 16 December 2025

1. GitHub Changelog index, checked 21 August 2026

1. actions/runner-images repository

1. CodeQL 2.26.3 improves GitHub Actions queries and JavaScript modeling — GitHub Changelog, 19 August 2026

1. Xcode 27 runner image now in public preview — GitHub Changelog, 16 July 2026

1. More control over your GitHub-hosted runners — GitHub Changelog, 25 June 2026

1. Actions steps can now be run in parallel — GitHub Changelog, 25 June 2026

Last updated: 21 August 2026.