I wonder if this basically needs to be treated like migrating a client from one root server to another even though that isn’t what is happening.
Basically backup the client settings, do the upgrade, then restore the client settings.
I also wonder if the correlation settings would help with this?
In a sense, to BigFix, this is like a computer going from AMD64 to ARM64 which would normally not be possible.
I’d hoped it would be handled as gracefully as the package update for a macOS “10.16” situation (which also appears as “x86_64” on ARM). Alas.
Not only that, it’s moving from i386 (and C:\Program Files (x86) to ARM64 ( C:\Program Files ).
Arrrgh.
I wonder if copying the data folder and maybe other folders from the old location to the new location before doing the install of the ARM agent would prevent the reset and the issue.
I would guess since the ARM agent is installed in a new location, the folder is empty, so then the client doesn’t see the existing agent’s certificates and so it resets.
This is quite hard for me to test. I need to figure out if I can snapshot my one VM I have that is Windows on Arm on my Apple Silicon Macbook.
I wonder how hard it is to run Windows on ARM on Raspberry Pi or something?
I’m going to test exactly this next. 
Welp. My support ticket ended in (paraphrasing) “this sounds like an enhancement request”. So I filed an idea.
Thanks for doing that. I know it is annoying to hear that a defect is an enhancement request, especially in cases where it is not that distinct of a difference.
If you or someone does have a working fixlet that does this transition, that would be helpful as a starting point. I’m not sure I have time at the moment to work on one, but I would like to. The hardest part is having Windows on ARM to test with.
What is your case number for your support ticket? I’d like to see if it is in our internal system so I can add to it.
Do you have access to an M-based Mac? I’m using VMware Fusion (now free) to run and test with a Windows 11 ARM VM on an M1 MacBook.
I forget that this is free now. I’ve been using UTM and it kind of works but not as well as I’d like. I’ll have to give this a try. I do have an Apple Silicon Mac. Seems like this is where to get it: Home - Support Portal - Broadcom support portal - Support Portal
This also seems like an option on Raspberry Pi: GitHub - Botspot/bvm: User friendly, high performance Windows 11 Virtual Machine on ARM Linux
This might be a good docker based option, but won’t run on MacOS, not sure that it would run on Intel either (need to already have linux on arm or windows on arm): GitHub - dockur/windows-arm: Windows for ARM in a Docker container.
I’m also testing with VMWare Fusion on an M Mac. Pretty great, testing-wise.
(I’ve also just filed a support case for VMWare Tools content to actually and only target x86_64/AMD64 hardware.)
One note from the support ticket. It sounds like it would NOT be possible to retain the same ComputerID when making the switch, even if that switch is done manually because the root server will see the change in the underlying hardware and force a reset which will cause a new computer ID.
This doesn’t mean doing it either manually or automatically isn’t possible.
Related to this, via Support and Engineering, the Windows Applications Extended fixlets for VMWare Tools (x86) now include this relevance:
("x86_64" = architecture of operating system) AND ( not exists (it as string) whose(it as uppercase contains "ARM") of values "PROCESSOR_ARCHITECTURE" of keys "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" of registries)
...and now they don't mistakenly try to install on v10 clients running in x86_64 emulation mode on a Windows/ARM machine. 