Looks incredibly complex and error-prone to me. Also, I'd personally always try to stick with officially supported or recommended methods if any way possible. If something does go south and you need MSFT support they might take some extra loops (=time) to figure out what the cause of the issue is and possibly deny support if they determine it isn't supported.
Don't get me wrong: Kudos for figuring out that workflow. But personally, I'd actually welcome the opportunity to wipe and freshly re-deploy those devices in to a guaranteed known good (and supported) state.
If it takes a day for folks to get back to work - so be it. I'd imagine there are many more switches that need to be flipped to the new organization, most of which are organizational and operational, not technical. So teams might even welcome a day or two during which other changes are finalized before everyone gets back to work.
Oh, and tech staff are used to lifts and shifts over the weekend, right? 😉
Besides, it'll give employees and their devices an opportunity (forced) to do other stuff too, such as:
- Re-register for MFA
- Familiarize themselves with their "new" accounts and work environments
- re-encrypt their FDE with better encryption such as xts-aes 256 (which doesn't happen using the process on getrubix).
- Eliminate stale GPOs and CSPs that don't go away unless you explicitly counter them.
- And a whole other bunch of stuff that accumulates over the years.
Lastly, it can give users a sense of celebration, when they sign-in to their new organization with a brand new environment. Those who reject their new environments won't stay long anyways.