After a few months of working with Microsoft Azure, you start to become familiar with the concepts behind the Resource Manager model and also how it is possible to move resources around, depending on business requirements. Whereas in the past, you would typically need to open a support request to Microsoft to complete this action, the vast majority of these operations can now be given to Azure administrators to finish instead. As such, we have the capability to:

• Move a resource into a different resource group
• Move a resource/resource group into a separate subscription, thereby altering its billing arrangements.
• Migrate an entire subscription to a new Azure Active Directory tenant, which alters both its ownership and billing arrangements in one fell swoop.

There are a few things regarding a resource/resource group that remain unchangeable post-creation. For example, its name and location (UK South, North Europe etc.) are static properties that cannot be altered for the entirety of a resources lifespan, and the only way to modify this is to delete and re-create it from scratch - action steps that have severe implications for a production workload. There are also a few scenarios where it will not be possible to move a resource to another subscription. The list of resources this affects is dwindling as the months go by, but there are still many popular services that are affected by this - such as Azure Data Factory, Logic Apps and Service Fabric. Partners who have a desire to move their customers away from Microsoft direct to Cloud Solutions Provider (CSP) billing need to take note in particular of these limitations when scoping any migration exercise, as it could be that an entire project becomes derailed if an un-supported resource is in the mix.

Sometimes, even if you think you will be OK when migrating a resource, you will occasionally hit an issue during the validation stage of a move. I came across a good example of this when attempting to move an App Service Plan and its corresponding App Service to a new subscription location, with the following JSON error message being generated (modified so that it is readable):

{
  "code": "ResourceMoveProviderValidationFailed",
  "message": "Resource move validation failed. Please see details. Diagnostic information: timestamp '20190221T124038Z', subscription id '4e846969-3196-476f-a088-6e393bb5ce98', tracking id '6cf8ddf7-8d15-48bc-8b34-f7729bd44f0a', request correlation id '68c44a05-eeba-4d96-887c-56a228ab69a3'.",
  "details": [
    {
      "target": "Microsoft.Web/serverFarms",
      "message": "{\"Code\":\"BadRequest\",\"Message\":\"Cannot move resources because some site(s) are hosted by other resource group(s) but located in resource group 'myoriginalrg'. The list of sites and corresponding hosting resource groups: 'myappserviceplan:myoriginalrg,mywebapp1:myoriginalrg'. This may be a result of prior move operations. Move the site(s) back to respective hosting resource groups and try again."\ ... }
    }
  ]
}

In this particular example, the App Service Plan and App Service had been the subject of a previous move operation from their original resource group (in this example, myoriginalrg) into the current resource group. The location of the original and current resource group when this move took place was in the same subscription, so the transfer completed without issue. Now, because I was looking to move the resources to a new subscription, the error message above appeared. What’s worse, the myoriginalrg resource group had been deleted a long time ago, meaning there it wasn’t immediately clear whether the option suggested in the error message was even possible. Fortunately, this was not the case, and the following workaround steps can be used to get your App Service Plan/App Services moved to your desired location.

1. Create a new resource group in the same subscription where the App Service Plan/App Service exists, with the same name listed in the error message (in this case, myoriginalrg).
2. Move the resources into the myoriginalrg resource group. Verify that this completes successfully.
3. Re-attempt the resource move operation to your preferred new subscription location. The procedure should complete successfully.

My main worry when I first saw this error message is that the resources in question were tied permanently to a non-existent resource group and that the listed workaround steps were not going to work. Fortunately, my glass half full outlook proved me to be categorically wrong, and the workaround solved the issue entirely. I can’t really understand or explain why an App Service Plan / App Service creates such a binding to a resource group (and, to a lesser extent, a subscription), which therefore causes an issue like this to appear; fortunately, as we have seen, there is a way of getting things working as intended without having to involve Microsoft support 🙂