On this page · 10 sections
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 would migrate to the Visual Studio 2026 image. On 20 August it set the rollout for 21 to 30 September, and by 20 October a job on that label was reporting the new image. Reading the two READMEs in actions/runner-images on 2 November 2026 shows what that swap actually does: Visual Studio Enterprise 2022 17.14.37710.0 is replaced by Visual Studio Enterprise 2026 18.11.12324.101, 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 on the VS 2022 image 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, with a $0.002 per-minute Actions cloud platform charge included in those rates, so the cost of a broken ARM matrix is now measured against a cheaper baseline, not a forgiving one.
Update, 2 November 2026. This page first said the switch would come in early September. On 20 August GitHub set a gradual rollout from 21 September, complete by 30 September 2026. GitHub has posted no completion note and its README still lists windows-11-arm separately, but a job on that label reported the Visual Studio 2026 image on 20 October, and the runner-images team described the label with that image's build numbers later that month. Treat the switch as done and check your own job log. The x64 labels windows-latest and windows-2025 already carry Visual Studio 2026, and our Visual Studio 2022 support guide covers the wider upgrade.
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. On 20 August 2026 the GitHub Changelog announced general availability of the image and gave the migration dates: the label would move gradually from 21 September, with the rollout complete by 30 September. That post named no VS 2022 fallback for ARM64 either.
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 said 18.7.11925.98, and on 2 November 2026 it says 18.11.12324.101. 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.
| Item | VS 2022 image (last README) | VS 2026 image (windows-11-vs2026-arm) |
|---|---|---|
| Image version | 20261006.188.1 | 20261026.197.1 |
| OS build | 10.0.26200 Build 9457 | 10.0.26200 Build 9711 |
| Visual Studio | Enterprise 2022, 17.14.37710.0 | Enterprise 2026, 18.11.12324.101 |
| Install path | ...\Microsoft Visual Studio\2022\Enterprise |
...\Microsoft Visual Studio\18\Enterprise |
| Windows SDKs installed | 10.0.19041.0, 10.0.22621.0, 10.0.26100.0 | 10.0.22621.0, 10.0.26100.0 |
| Android NDK | R23C | R27C |
The age gap has reversed. On 21 August 2026 the VS 2026 image was 26 days older than the VS 2022 one, so most tools on it sat one patch behind. On 2 November 2026 the VS 2026 README is 20 days newer than the last VS 2022 README: Node 24.22.1 against 24.21.0, Python 3.13.17 against 3.13.16, Git 2.56.0.windows.3 against 2.56.0.windows.2, PowerShell 7.6.9 against 7.6.6, Kotlin 2.4.21 against 2.4.20, Bicep 0.48.1 against 0.47.16. CMake 4.4.4 and Gradle 9.8 match. The tool step backwards this page warned about has gone, and the compiler change is what remains.
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.
| Capability | Present on the VS 2022 image | Present on the VS 2026 image |
|---|---|---|
32-bit ARM native tools (VC.Tools.ARM, VC.ATL.ARM, VC.Runtimes.ARM.Spectre) |
Yes | No |
Windows 10 SDK 10.0.19041.0 (Windows10SDK.19041) |
Yes | No |
Xamarin (Component.Xamarin) |
Yes | No |
| Coded UI Test and Web Load Test adapters, Dotfuscator | Yes | No |
The main ARM32 components in the VS2022 image, meaning the current compiler toolset, the ATL headers and the Spectre-mitigated runtimes, are absent from the VS2026 image. Only the older 14.29 ARM toolset stays. A native project still emitting an arm (not arm64) configuration will not find a current 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.110.9434, 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 VS 2022 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.118.0 with NDK R27C against 35.0.78.0 with NDK R23C, and a newer Windows SDK component, 10.1.26100.9457 against 10.1.26100.7705. If your workflow shells out to R, both READMEs now mark R 4.6.1 as x86_64 and emulated, so the switch does not change that.
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 current toolset backing it does not exist on the new image, only the older 14.29 one. 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 now
| Date | Event | Action |
|---|---|---|
| 8-15 June 2026 | windows-latest and windows-2025 moved to VS 2026 (x64) |
Already done; windows-2022 remains the x64 escape hatch |
| 11 June 2026 | windows-11-vs2026-arm preview opened |
Preview over; generally available since 19 August 2026 |
| 21-30 September 2026 | windows-11-arm rollout to the VS 2026 image (GitHub's target) |
Window has passed; check your job's image and fix what breaks |
If a job fails, read its Set up job log, which shows the image version, then pin the label to windows-11-vs2026-arm in a branch and run your full matrix against it. That label is generally available and is the image GitHub said the migration would deliver, so a green run there is a real result, not an approximation. If something still fails, fix it using the checks above or raise it in actions/runner-images, which is where GitHub asks for problems with this image to be reported.
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 now. Issue #14602 gives similar advice to teams that need an image without Visual Studio: a self-hosted runner or another supported image. GitHub's December 2025 pricing 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. A short ARM64 matrix run pinned to the new label is cheap next to a morning spent bisecting a compiler change.
What is still unknown
GitHub has now given dates: a gradual rollout from 21 September, complete by 30 September 2026. That is close to the one-week x64 move, while the macos-latest move took 30 days. What GitHub has not done is confirm that the move finished. Issue #14602 is still open, a user's question there on 13 October has no reply from GitHub, and the README and docs still list windows-11-arm and windows-11-vs2026-arm separately. The evidence that it happened is indirect. A job on the windows-11-arm label on 20 October reported image windows-11-vs2026-arm64, and the runner-images team on 26 and 27 October described windows-11-arm with build numbers 20261021.192.1 and 20261022.194.1, which exist only as VS 2026 image releases. The last separate VS 2022 image release is 20261006.188, published on 14 October. And GitHub 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 new 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
Last updated: 2 November 2026.
