This year´s Ignite was stunning! Microsoft announced a lot of new features and services to help customers achieve more in their IT landscape! My highlights were definitely the WVD sessions presented as well as the superb Ask the Expert sessions with a lot of well-known supporters in the community!

And then I discovered a new service in public preview called “Azure Resource Mover”. A service built to help growing companies to transfer their resources to other regions without recreating them… and this is insane!

I´ve checked out the documentation and tested it in a real-world example, when I want to move my existing Session Hosts to a region closer to my end users.

To test this I´ve created a new resource group with a virtual machine, which is acting as a Session Host and which should be transferred to the new region. This virtual machine has a standard configuration for testing purposes and comes with a simple NIC and a managed disk.

The resource groups for the target region in Germany West Central are already prepared, VNET and Domain Controllers are already in place in the new region, so there is only the move itself left!

So what exactly is this Azure Resource Mover service and what is this thing technically doing?
Diagram showing the move steps
Picture from Microsoft:
  1. The first step is to select the resources you´d like to transfer! A tip from my side is to just pick the Virtual Machine objects, the dependencies will be identified by the service itself!
  2. The dependency check will be performed, identifying that you need to move other resources along your virtual machine (Resource Group, NIC, Managed Disks etc.)
  3. Start the preparation. This step initiates the preparation while creating a resource group with a dedicated Storage Account and a Recovery Services Vault to perform the move.
  4. Move initiation starts the process of transfering the resources to the target region.
    ATTENTION! Resources might be temporarly not available – perform these steps OOBH!
  5. Commit your move or discard the move! Depending on if you want to complete the move process you can decide wether you want to keep or remove the replicated resources.
  6. Delete the source is the cleanup step required to remove the source resources from the region you have transferred from.

Also, keep in mind that there is a limitation in resources you can move for the moment. The service is still in Preview and supports only:

  • Azure VMs and their disks
  • Network Interface Cards
  • Availability sets
  • Azure VNETS
  • Public IPs
  • Network Security Groups
  • Internal as well as Public Load Balancers
  • Azure SQL databases and elastic pools (very interesting!!)

Additionally, keep in mind, that for the moment, only these OS types are supported for this migration type:

  • Windows Server 2008 R2 SP1 – Windows Server 2019
  • Windows 7 SP1 – Windows 10
  • Several Linux Distributions

The complete list of supported OS can be found on the official documentation page:

The big question is if it makes sense to use this service for Windows Virtual Desktop when you can simply deploy an image via a Shared Image Gallery?

And my answer is, YES ABSOLUTELY! Imagine, you´re about to move a persistent Session Host, with a legacy software installed on it, which doesn´t allow to generalize the image? I just had some cases like this and this way helped me to replicate the Session Host to the destination region for better performance.

So lets get started…

Like I´ve mentioned before the setup is quite easy for testing purposes. I´ve created a dedicated Resource Group, with one Session Host (Virtual Machine), which should be transferred to a new region for better latency.

The source region is West Europe and the target should be Germany West Central.

To get started, we select the Azure Resource Mover service from the search bar:

In the service itself, we have only one option first, the “Get Started” button. We proceed by clicking this button:

Now we need to select the source and target region of our resources to be transferred:

The next page allows us to pick the resource we´d like to transfer! A tip from my side, select the Virtual Machine only, the dependencies will be presented to you while validating those.

Now I select the virtual machine I´ve mentioned earlier and click on “done” to complete the selection process:

The next page explains the steps the Resource Mover is performing and which resources will be created to perform the move (see last line where you need to hit the checkbox):

The process of the creation of all required resources takes approximately 2 minutes. Once this is done we´re presented to the Azure Resource Mover portal, where we can navigate on the left side to the point: Move options > Across regions.

Now we can see our virtual machine and a validation process that needs to be performed before we can proceed. We click on “Validate dependencies” to identify the objects we need to move alongside the Virtual Machine object.

After 2 more minutes, the dependency check has been completed and we can see the resources that must be moved additionally. To proceed click on Add dependencies.

It is clear to move our NIC and the Resource Group to the new region, so we select both resources identified:

The resources will be added and the expected result should look like this:

Now we need to modify the target region settings like the target VNET or target Resource Group, if we´ve created them already. Both resources can also be created directly from within the agent. First we will modify the network card settings, which requires us to click on:

Now you have the chance to adopt some parameters if needed. But the most important thing is to address the resources already available to me. So I click on “Show Details” in the lower third of the screen.

I´m selecting the resources I´ve already created for the network and the resource group and finally click on save in the upper left corner.

To complete the process of validating our dependencies, we have to click on the blue button again and wait for 2 more minutes:

The screen we should be presented with should look like this:

In my case, the configuration for the resource group selection didn´t work, so I had to select my preferred RG again while clicking on “Destination configuration” for the RG.

Now we need to select our Resource Group first, and click on Initiate move to start the preparation:

Once this is done we can click on commit move for the resource group. The final result should be that the status of the RG is changing to:

Now we can proceed with the preparation of the VM and NIC. We select both objects and click on the prepare button.

The preparation took about 15 minutes to complete. Once this is done, you´ll see the following result:

The status has changed to “initiate move pending”. So we select the two objects again and initiate exactly this move, by clicking on the button in the top menu bar. The resources will now be presented to us, so we just need to confirm the selection:

What I really like to see with this service is, that there are frequent dependency checks to validate that in the meantime no configurations on the machines itself have been changed. If everything was okay, you can see that the status for the computing resources has been changed to commit move pending.

We select the two resources again and want to perform the final step, the transition to the new Azure region:

To do so, we select the two objects again and commit the move! At this stage we also get the option to discard the move and revert the already made changes to the target region. While committing the move we can already see our new resource being created in the Germany West Central region.

Finally all resources have been shifted to the new environment and the expected result from within the Azure Resource Mover should look like this:

This gives us the possibility to test our environment and to simply validate if all apps are running as expected. To validate what´s going on behind the scenes I´m changing my view to the Virtual Machines and we can see that there are two virtual machines in the source and target region, while the target region is running and the other one is deallocated. If we finished our migration, we can simply delete the source Virtual Machine with corresponding resources (NIC + Disk) to complete the migration:


I love this tool already now! It helped a customer of mine to cover exactly the case of not being able to capture an image and redeploy it in another region! The process was relatively streamlined and did what it should do! Remember, this was a test environment. In production WVD workloads I highly recommend also to re-register the new Session Host with the Host Pool to see if everything is working fine. In my example and after the move everything has worked properly without any changes! Nevertheless it´s better to validate, before running into any issue!

In the not too far future, I will create a video on showing you exactly the process, for now I can say that this tool, even if it´s in Preview saved my day!



(Visited 938 times, 1 visits today)


  1. Maxim Sokolov September 25, 2020 at 3:23 pm

    It looks like Azure Site Recovery for VMs TBH.

  2. Pingback: WVD Weekly blog post 20th September – 27th September - WVD Community

  3. Sujay September 30, 2020 at 6:35 am

    Great blog post @Patrick on how Azure Resource Mover can be used to migrate WVD Resources!!!

    Hi @maxim…Azure Resource Mover currently uses Azure Site Recovery replication technology for VMs underneath, but it provides simplified experience for migration…Also, Resource Mover supports SQL Azure DB, Elastic pools and other networking components with a consistent experience…and we plan to support more Azure resource types for migration across regions with same experience through Resource Mover in future…

    Sujay Talasila
    Senior PM Lead,
    Azure Resource Mover

  4. Pingback: Migrate WVD Resources with the new Azure Resource Mover to other regions –

  5. Pingback: WVD news of the week - Ignite February 2021 Edition - Johan Vanneuville

Leave A Comment

Your email address will not be published.