The only time you really care about the CPU architecture is when you're writing in assembly language. For the most part, when you're writing in C++ or any other modern language, you don't need to know what CPU you're writing for. (The exception has to with things like byte packing and integer size, but those can be addressed as-needed.)
If the OS has the same API's, then it's mostly a matter of clicking "Build" with the compiler's output set to the right CPU. There are often subtle differences in the OS caused by the requirements of different architectures, but those are porting issues, not "starting from the ground up" issues.
Ask all the Apple developers how hard it was to switch from PowerPC to Intel. I'm pretty sure they'll tell you they didn't have to rebuild their application from the ground up.
Austin Meyer builds X-Plane, a flight simulator (possibly the most intensive, power hungry application you can run on a PC), for PC, Linux, and Mac. He does have to do some porting to bring Mac code to the PC, but it's hardly "from the ground up."
Yes, ARM uses a very different machine language than x86, but when you get to the C++ level, you don't know or care what CPU you're running on... and if you're running a bytecode language like C#, you care even less, since the CLI or Java VM takes care of it.
If Microsoft did release a full-blown desktop OS for ARM Windows, you can be certain that they would design in all the API's we're used to, just like they did for PowerPC and Itanium architectures. Heck, even native 64-bit programs require recompliation. It's really not that hard.
Do you have to rebuild your programs from scratch for Metro apps? Yes. But that's because Metro is a whole new set of API's. That has nothing to do with ARM.