What Do I Need to Consider for Migrating Subscriptions with Multiple Resource Groups?

The choice between migrating resource-by-resource or redeploying depends on what you want for your end state. If your current infrastructure is a bit messy or you have issues you want to avoid carrying over, redeploying with Infrastructure as Code (IaC) would be a better long-term option. But if everything is stable and you need to move quickly, go ahead with resource migrations while keeping an eye on dependencies, identity mappings, and any services that might experience downtime. A mix of both strategies might work best for your situation, especially for those 25 resource groups.

When it comes to a large subscription migration, planning is key. Make sure to map out the dependencies first because some resources are tricky—if things like VNets or managed identities aren't migrated in the right order, it can lead to issues. Try to group resources that can be moved together and consider addressing tricky dependencies on a one-by-one basis. It can save you from unexpected surprises down the line.

Start enforcing strict naming conventions and tagging from the very beginning. If you let developers create resources with random names, your billing can get out of hand really fast, and it becomes tough to trace costs back to specific resources. Implementing Azure Policies early on is crucial to keep your cloud spending in check.

You've got to consider several factors like region, resource capacity, management groups, RBAC settings, and roles. It's a good idea to ensure that everything that needs to be registered is taken care of too, plus check on resource quotas—especially if you're moving regions. Definitely more to the process, and Microsoft has official guides that can help out!

Don't forget about downstream workloads that rely on any endpoints. From my experience, migrating typically preserves endpoints, while a redeploy might create new ones, which could throw a wrench into your existing setups.