Note: My particular case turned out to be very simple and worked without any manual intervention. You should however verify and test everything on a non-production environment before you move production resources around.
If you have been following my previous posts, you’ll know that I did spend quite some time in the Cloud Adoption Framework and have been guiding companies with ‘cleaning up’ their Azure tenant. On a regular basis, I’ve heard the comment “At some point we’ve considered moving those resources to that subscription, but never got to it as this would have been a lot of work to recreate or retest everything”.
We’ve had the possibility to move subscriptions to another tenant and move resource groups between subscriptions for quite a while. But there was a whole list of resources that weren’t able to be moved or having to open a command line interface scared people away. A direct CSP I’ve been in contact with, even had a script to check an exported list of resources to verify if they would be able to migrate the resources.
The problem
To be honest, I haven’t moved any resources around in the past few years myself, until this week. I had an expiring sponsored Azure subscription and needed to move the resources on it to another subscription. Since I had most of it automated, I could recreate everything in maybe half an hour of actual work. But as I didn’t want to mess around with DNS propagation etc, I decided to check out the current state of moving Azure resources between subscriptions.
The first step (in the past) to do is check if the resource types are movable, for that you can use this page. When I compared that list to my short list of actual resources, I noticed one issue: Static Web Sites are not moveable.
However, this can be very cumbersome if you have a lot of resources, cfr. the script that the direct CSP had to automate this. However the Azure Portal UI allowed me to select all resources so I just went with it for the sake of testing out.
Once you select ‘Move to another subscription’, you’ll be able to specify the target subscription (on which you should have the right RBAC roles) and the name of the resource group.
The next step is a validation screen. This validation step can easily take a few minutes, but I was pleasantly surprised that everything was green to move, even the static sites.
Simply start the move and sit back, this process can again take some time. Once everything is transferred to the new subscription, you will of course have to test everything out. At first everything seemed fine in my scenario: I had my static website available at the correct DNS address without having to change anything else in the Azure Portal or my DNS provider. More extensive testing showed that my images weren’t being served yet. Turns out that CDN endpoint had to be restarted and everything was fine.
Conclusion
Thanks to automation, I could have simply recreated everything in almost the same period but would have had to deal with DNS changes. And we know how annoying that can be.
I wouldn’t have expected DNS and CDN profiles to migrate that easily. And even though the documentation said static web sites could not be moved, everything turned out fine. So if you feel the need to move some resources, have a go at it with non-production resources and you might end up with a positive experience.