Down from the cloud: Moving Azure VMs to on-premises servers

Many IT pros have become experts at migrating an on-premise server to Microsoft’s Azure cloud. For those who haven’t but want to, there are a lot of tutorials on how to do it. But what if you want to move your virtual machine from Azure back to your on-premise environment? There’s not much information on how to do that, but luckily you’ve come to the right place. In this article, we will give you a step-by-step guide to do just that. The on-premise environment we will be using is Windows Server 2016 and a Hyper-V cluster.

There are a couple of ways to move a VM from Point A to Point B. We will focus on a simple but effective method that can be applied to small to medium migrations. We will be doing everything manually, but we can optimize a good deal of the tasks later on.

The entire process consists of a three tasks, and those are: assessment of the Azure environment, copying the VHD, and, finally, creating the VMs to match the previous assessment.

Assessment of the Azure VM

The assessment phase is key to save time during the transition process. The idea is to create a Word or Excel file to document all the information gathered on this phase and use it during the transition process.

Although we will create new VMs in the on-premises environment using the disks that were being used in Azure, we must make sure that the CPU, memory, and disk names are properly documented.

In this article, our goal is to transition the entire SharePoint test environment, and the first task is to check how many VMs are involved on the process. If you have organized your environment using Resource Groups, then for you this step is a piece of cake. List the Resource Group and all VMs in use will be listed. From the list below we see that we need to migrate five VMs over.

Azure Resource Groups

The second step is to stop all the VMs that will be migrated. Keep in mind that this will bring the service down, and such outage must be planned and, of course, your end-users must be informed. To do that, just click on the desired VM, and on the new blade click on Stop and then Yes.

Stop Azure virtual machines

The third step is to document the current utilization of memory and CPU. This can be accomplished by clicking on the desired VM and then clicking on Overview. On the new blade that is displayed on the right side, we will have the Size, which gives us that information.

Check VM CPU and memory size

The final step of the assessment is to identify the disk names. This can be done by clicking on Disks. On the new blade, a list of the OS Disk and Data Disks that are in use by the current VM will be listed. We will click on each entry on the left and we will copy the disk name listed on the blade on the right side. (There is a copy button available when you select the field.)

Copy the VM disk names

The results of the current assessment should be a table like the one below, where we have all the information required to create the new VM on-premises and associate the correct disks to them.

Collected VM information

Copying the VHD files

The second phase consists of using Microsoft Azure Storage Explorer utility. (You can use this link to download it, and it can be used on Windows, Mac and Linux.) The installation process is simple and does not require any additional configuration. Just use the default values.

To make things easier, we will create a volume to hold the VMs from the SharePoint test environment, which happens to be all the VMs that are in Azure. That volume is being shared among all nodes of the Hyper-V cluster on-premises.

After opening the Microsoft Azure Storage Explorer, click on the second icon to configure an account. This process will create authentication with the Azure service. After it is authenticated, a list of all storage objects will be seen on the left side. Expand the ones related to the VMs to be transitioned, then expand Blog Containers, and then vhds. Select each VHD listed on the right side and click Download.

Microsoft Azure Storage Explorer

Each download will be listed on the bottom right side with its respective progress on the copy process. Wait to get all of them completed before moving forward to the next phase of the transition.

Download all VM disks

Finishing the transition

The easiest way to create a VM using an existing disk that is already stored on the volume where the future virtual machine will reside is using the Failover Cluster Manager. This is the way to go even if you have Virtual Machine Manager implemented.

The process is simple. Log on to the Failover Cluster Manager, right-click on the Roles, and click on Virtual Machines… and then click on New Virtual Machine… A new window listing all nodes will be displayed. Click on any available node and click on OK.

In the Before you Begin welcome page, just click Next.

In the Specify Name and Location page, type in the name of the VM and define the location to be the root folder of the volume that contains all disks. Click Next.

Create new virtual machine in Failover Cluster Manager

In the Specify Generation page, select Generation 1 for now and click Next. Note: We are going this way because these days virtual machines in Azure are created using VHD. We could convert the disk to VHDX and then use Generation 2, but for the sake of simplicity we will not change the disk format for the purposes of this article.

In the Assign Memory page, use the same amount of memory that the VM used to have on Azure and click Next.

In the Configure Networking page, select the Virtual Switch used by the VMs and click Next.

In the Connect Virtual Hard Disk page, select Use an existing virtual hard disk and click Browse. Go to the volume that has the OS Disk that we already copied from Azure and select it. Click Finish. Note: For now, we will configure just the OS Disk.

Connect virtual hard disks

A new wizard to configure the High Availability will be displayed. Just use the default values to complete this part of the process.

Now, let’s go back to the main page of the Failover Cluster Manager. Right-click on the virtual machine that we have just created and click on Settings. In the new page, select IDE Controller 0, select Hard Drive and click on Add. A new disk will show up underneath the existing IDE Controller. Click on Browse… and select the data disk available. You can repeat this process if the VM has additional disks.

Add data disks and edit CPU core count

Before hitting OK on the VM Settings, click on Processor and match the number of CPUs that this new machine will have with the Azure configuration.

Testing and final touches

Now that the VM was created, it is time to fire it up. After the initial boot, the administrator must work on some minor details:

  • Page file
    By default Azure uses Temporary Storage on drive D: and as you may have noticed, we didn’t copy the Pagefile. So, we need to create a new one or configure it properly
  • Time Zone configuration
    Make sure that the Time Zone configuration is set accordingly with the site of the new VM
  • IP configuration
    The VM is using DHCP because we created a new VM. By doing that, a new network adapter was associated to the operating system. Make sure to configure the IP and wait for the DNS replication to take place and then update the entries.

One last piece of advice: After testing the entire process and making sure that your VMs are up and running on the on-premises environment, it is time to do some house cleaning. Specifically, this means the removal of the former VMs from Microsoft Azure.

About The Author

8 thoughts on “Down from the cloud: Moving Azure VMs to on-premises servers”

  1. We are planning on moving the production SharePoint servers from Azure to on premise. We have a plan to keep the same server name in on premise environment as well as the URL shouldn’t change(Please see the note). Is there anything I should keep in mind in terms of SharePoint configurations?

    NOTE: Please note that the web applications and site collections are created using the name of the server.

  2. You may want to disable the Azure Telemetry services afterwards and you have to change the windows license. Either a AVMA key or a normal Windows Key matching the product version. Product version change is possible with dism, key change with slmgr.

    As long as you move the whole server vhds, the settings, including server name and so on, are still the same. It may be a bad idea to move a domain controller, (just set up a new one and sync, check roles before demoting the azure dc) and servers that rely on connections to other services on different machines may need some inspection and configuration changes (SQL etc.)

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top