The cloud offers many new possibilities and is available at the push of a button. And this is exactly what holds various dangers. You start your cloud adventure, start the first services and then soon realize that you made a mistake, for example choosing the wrong type of subscription. Usually you have also spread your services over different resource groups. I have therefore often been confronted with the question "How can I migrate the existing Azure Services distributed in multi resource groups to a new Azure Subscription? With this article I try to answer this question as comprehensively as possible.
Viability of migration to new Azure Subscription
The first question to be answered is whether a migration from Azure Services to a new Azure Subscription is even possible. There is no clear answer to this question. While most services can now be migrated without problems, there are still certain types of resources that have limitations or simply cannot be migrated. First get an idea which resource types you would like to migrate. The easiest way to do this is to use the following PowerShell script.
$DesktopPath = [Environment]::GetFolderPath("Desktop")
Set-ExecutionPolicy Unrestricted
Import-Module -Name Az
Connect-AzAccount
Get-AzResource | Select-Object -Property Name,ResourceType,Sku | Export-Csv -Path $DesktopPath\azure-resource-export.csvThis script connects to your subscription and exports all your Azure Services into a clearly arranged CSV and saves it with the name "azure-resource-export.csv" on your desktop. You use this CSV to evaluate the migration capability. This is because certain services have limitations.
Services with limitations
The number of services that have limitations has steadily decreased, so that today there are only a few. The following table shows the limitations that seem to me to be the most important.
| Service | Description | Migration possible |
|---|---|---|
| App Services | Can be migrated, but only from the original resourcegroup where the service was created. Make sure that you migrate all dependent services from this resource group. | With limitations |
| Azure Active Directory Domain Services (AAD DS) | Migration to a new Azure Subscription is not supported. | Not possible |
| Recovery Services | Regional conditions. A few regions are not supported. In addition, a protected VM should be migrated together with the Vault. Restorepointcollections cannot be migrated and must be deleted before migration (usually non-critical). | With limitations |
| Marketplace – Services | Services created from the Azure Marketplace can NOT be migrated. Even if it is only an Azure VM, for example. | Not possible |
Since Microsoft is striving to further minimize the limitations, this list should by no means be considered complete. A complete and up-to-date list of limitations can be found at the following link. https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/move-support-resources
Compare your CSV list with Microsoft's list and see if your services can all be migrated easily, if a workaround is needed, or if migration is prevented (for example, by AAD DS).
System Impact of Migration
Before proceeding with the planning of the migration, you should ask yourself what impact the implementation will have on the existing Azure Services, during and after the migration. The answer to this question is definitely positive. This is because the migration of resources to a new Azure Subscription has no direct impact on the service itself. While Azure freezes the resources during the migration process and thus protects them from changes, the actual service continues to run without interruption. A migration in itself therefore has no impact on the day-to-day business. Nevertheless, an announced maintenance window is usually necessary. This is because an Azure resource has a specific resource ID, which is partly made up of the Azure Subscription ID. So if you migrate your service to another subscription, the resource receives a new resource ID. Example: https://portal.azure.com/#@graber.cloud/resource/subscriptions/500axxxx-xx00-00xx-x0x0-xx000xxxx0xx/resourceGroups/RG-name/providers/Microsoft.Network/dnszones/graber.cloud/overview
(The marked part changes = Subscription-ID)
So you should check if this ID is in use. Unfortunately, the only way to find out is through your hopefully available documentation. Otherwise "Trial And Error" applies.
- If you point to this ID with one of your applications or custom scripts, you only need to adjust the Subscription ID part of the Resource ID string after migration is complete.
- If the resource ID is not in use, you do not need to pay attention to this.
Note: If you did not notice that the resource ID is in use, you can simply migrate the resource back to the "old" subscription after the migration to undo the ID change.
Performing the Azure Subscription Migration
Once you have checked the above mentioned points of doability and you and your resources are ready for the migration, you can proceed with the following steps. Note that in this scenario the resources are distributed among multi-resource groups. If you already have all the resources to be migrated in a single resource group, you can skip the following subchapter "Consolidation of multi - resourcegroups".
Consolidation of multi - resourcegroups
If your resources are distributed in different resourcegroups, you must first consolidate them into a single resourcegroup. This is because resources have dependencies, but only one resourcegroup and its azure resources can be selected for the migration job. For a better understanding I assume here for example that VM01 is placed in resourcegroup "RG01" and the Azure Backup "Bckp02" of "VM01" is placed in resourcegroup "RG02".
Before you continue, make some kind of note of how your resources and resourcegroups are organized so that you can restore this order on the new subscription at the end. Once you have made a note of this, move all your resources into the same resourcegroup. In this example "Bckp02" from "RG02" to "RG01". Select the resourcegroup "RG02" to be moved and click on "Move" and "Move to another resource group" under "Overview".
Now a list of all resources of the resource group appears. Make sure that you select all resources you want to migrate (usually all of them). Also select the target resourcegroup (here "RG01").
Then confirm with "OK". Azure now verifies the migration for executability. This takes a few minutes depending on the number and type of services. If everything is OK, the migration starts automatically. If the resourcegroups to resourcegroups migration was successful, you now have all your resources to be migrated into a single resourcegroup ("RG01"). This is the basis for you to proceed to the next step.
Note: If you are using App Services, remember that you must use the App Services resourcegroup for migration. This is therefore the resourcegroup in which you collect all other Services before Subscription - Migration.
Azure Subscription Migration
Before you start the actual migration, check again that you have followed all preparations.
- You have executed the PowerShell script to export the resources and saved the CSV file.
- You have checked the services in the CSV file with the list from Microsoft for their migration suitability.
- You have validated if and which applications and scripts access a resource ID to adjust it after migration.
- You have scheduled and communicated a maintenance window for the migration (not necessary, but recommended).
- You have written down the initial situation of your resources and resourcegroups so that you can restore them.
- You have consolidated all resources to be migrated into a single resourcegroup.
The preparation itself is the essential work. The execution of the migration itself is easy if the preparation is clean. If you have made all the preparations conscientiously, then you are ready for migration. Navigate to the resourcegroup whose resources you want to migrate (in example this would be "RG01") and click "Move" again. Now select "Move to another subscription".
Just as with resourcegroup consolidation, you can now select all the resources you wish to migrate. Select the new Azure Subscription to which you want to migrate the resources and create a new resourcegroup with the same name as the existing one (example: "RG01").
Again, Azure automatically verifies the feasibility of the migration, which can take a few minutes. Migration to the new Azure Subscription is then automatically initiated. Please note that this may take a little longer for a new subscription, as Azure first has to register all necessary resource providers on the Azure Subscription. You will be informed as soon as the migration was successful.
Congratulations. If Azure did not issue any errors, you have successfully migrated your resources to a new Azure Subscription.
Post – Migration Check
After successfully migrating your Azure resources to a new Azure Subscription, there is still more to come. You still have a few, but still important tasks ahead of you.
Split in Resourcegroups
Now move your resources back into the desired resourcegroups. First create all resourcegroups you need on the new subscription. Use your preparation notes to make sure that you can create the same structure again. So create one resourcegroup after the other and then move the resources to the desired resourcegroup as before with "Move". Repeat this process for each resourcegroup until you get the structure back (in the example "RG01" with "VM01" and "RG02" with "Bckp02").
Azure Resource-ID adjustment
Once you have obtained the desired resourcegroup structure, the ID of the Azure resources will not change. Now add the new resource ID to all your scripts and applications. You have already taken this from the preparation of your documentation. Once you have made the changes, check the functionality of the scripts and applications.
Communication and closure
If you made the preparations properly, you should not have had any problems with the migration itself. If you have done the complete Post - Migration Check successfully, the migration is now complete and successful. Communicate the success of the Azure Subscription migration to the appropriate authorities and thus officially end the maintenance window.
Congratulations on the successful migration.
English 
German