Migrating a VM to Azure

The following is the work of Aaron Whittaker and should not be reproduced without prior permission.

Here are the steps to successfully migrate a VM to Azure with a reboot only outage.

The source VM can be hosted on any platform.  I started with an ESX VM, but changed to a Hyper-V VM part way through due to limited resources within my lab.  Hint, hint vendors 🙂


1 Azure subscription

2 Azure VM’s(DTTarget2 – destination, DTTarget3 – management server)

1 Azure network with PTS VPN

1 virtual host (any Hypervisor)

1 local VM’s (Win2012R2)

Double Take Move

Double Take Move licenses (these are not free, even for testing)

A lot of time for the sync/migration..

It is important to know that this is only method I have found that offers essentially zero outage (reboot required).  Even though there is limited outage, there are items which may cause a longer outage time than just a reboot.  Authentication, DNS, SQL and App server and other potential interconnected and dependent services.  If this was production environment then hopefully a STS VPN would be established and a PST VPN would not be required.  This would help greatly with outage and VPN disconnection issues that I saw due to my slow and unreliable residential internet connection.  If you already have a STS VPN running you can ignore the VPN and Certificate steps.


Firstly created a VPN on your network

You can follow my instructions in more details in a previous post here.


Create a network or use your existing, when configuring it or after you can check the option is allow PTS connectivity (VPN).


Create your certificate and upload it as shown here.


Go back to the dashboard page and download and install the VPN client on the VM to be migrated.

Once downloaded install, you may get an application signing error just ignore and select more detail to install.


Azure VM’s

Create two small vm’s in Azure.

On all VM’s I stopped my internal/domain Windows firewalls on Private to ensure this caused no issues.

Name resolution appeared to be a problem for me.  The Azure VM’s could not resolve the source VM that was using VPN.  The way I resolved this was to simply add the Source VPN IP to both Azure VM’s host file.  A problem that I faced was each time my VPN connected I received a different VPN IP address.  This meant I had to change the host files each time the VPN reconnected.  I did not find away to statically assign the ip to a VPN client within Azure. Please comment below if anyone has any ideas on this.

I then installed the double take move software on all 3 servers.  I installed the client and server components on each server.  The product can be downloaded here


but as I mentioned won’t work without purchasing licenses.  The reason for this is if you did use the ‘trial’ once you would then have no need to ever buy the product.  It should also be note that you can migrate the same licensed source server as many times as you like within 60 days.  After that the license expires.

Once it is installed open and go to manage servers.  Add the source and destination servers as shown below.


Once everything is polling correctly (DNS) select Get Started, and Double-Take Move.  Then select the source server.


Then select Full Server Migration and the c: and the d: (additional drives [3+] will require additional destination configurations.


Select the destination server.


The options that I selected include, retain target network configuration, enable medium compression.


Once you are happy with the checklist select Finish.


At this point once it starts it would be worthwhile leaving everything while it syncs.  Sync time will depend on source workload, rate of change, disk size, destination VM size, upload link speed, internal infrastructure bottlenecks may effect this speed as well. I used a 20m upload to sync 4.3gig uncompressed in 2 hours.  This was on a 12 gig VM.  My guess is it used previously failed synced data (9 gig mirror skipped).  My earlier jobs failed due to my internet link resetting at midnight.

Once the job is complete we see that server now shows as being protected.


We can also check the destination server to ensure that the source files have in fact replicated across.


Now to fail over to Azure we select the failover button, or right click the server and select failover.


Leave the default settings to sync all latest non sync’ed data during the cutover.


What happens now?  The source server turns off after a shot amount of time as there would have been minimal changes that need to go across on the final sync.

The console will change to this below, don’t worry about the red icon this is expected.  The destination server will reboot.  As the server settings are applied, eg. Server name, register, domain membership, ip address (if selected), and all files go to their original location.


I logged back onto the destination Azure VM, to see the server name had changed, and it was on the original on premise domain.


The staging folder remained but the data had been moved to the correct locations.

The data was also retained on D:


So the tool should meet most migrations except the ones where there is a large amount of data change.  It may change far too often and not be a viable candidate.  Eg. Very large SQL server.  From what I have seen you could always try and if this fails nothing has been lost, just an agent to be removed from the source SQL server if it fails.  The server agent will also need to be removed from the server with Azure.  This tool does not change the VM name with the Azure console.  So name the server correctly before starting.  Source and destination must have a different name.  You may need to call the server eg. A-Win2012R2.  Another option would be to replicate, fail over, delete the server, keep the VHD in Azure create a new VM with the VHD using the correct name all via PowerShell.  But this will result in outages.

It should be noted that you don’t actually need to install the management server.  But this will come in handy if you are migrating many VM’s.  Additionally if you install just the client, this is what you use to connect to the management server.  The client is not an agent.


Here are some Double Take Common job issues for reference:

The following issues may be common to multiple job types within Double-Take Availability and/or Double-Take Move.

  1. If you have specified an IP address as the source server name, but that IP address is not the server’s primary IP address, you will have issues with snapshot functionality. If you need to use snapshots, use the source’s primary IP address or its name.
  1. Only one primary IPv6 address can be monitored for failover when using the replication service monitoring method. Therefore, if you have multiple IPv6 addresses per subnet, failover monitoring may not work properly with the replication service monitoring method. To ensure proper failover monitoring, use IPv4 addresses or use only a single IPv6 address per subnet with the replication service monitoring method. You can also use the network service monitoring method with any IPv4 or IPv6 configuration.
  1. If you are using Windows 2008 R2, virtual hard disks can be mounted and dismounted reusing the same drive letter. However, once you have established a job, you cannot mount a different virtual hard disk to the same drive letter used in your job. This could cause errors, orphan files, or possibly data corruption. If you must change drive letters associated with a virtual hard disk, delete the job, change the mounting, and then re-create the job. This issue may be resolved in a future release.
  1. If you are using SQL to create snapshots of your SQL database, the Double-Take Availability verification report will report the file size of the snapshot files on the source and target as different. This is a reporting issue only. The snapshot file is mirrored and replicated completely to the target. This issue may be resolved in a later release.
  1. If you are using HP StorageWorks File Migration Agent, migrated files will incorrectly report modified time stamp differences in the verification report. This is a reporting issue only. This issue may be resolved in a future release.
  1. During the job creation process, the Double-Take Console may select the wrong route to the target on the Set Options page. Make sure that you confirm the route selected is reachable from your source. This issue may be resolved in a future release.
  1. If you are performing DNS failover but your source and target are in a workgroup, the DNS suffix must be specified for the source NICs and that suffix must correspond to the zone name on the DNS server. This issue may be resolved in a future release.
  1. In a cluster configuration, if you add a possible owning node to the protected network name after a job has started, you must stop and restart the job. If you do not, the records for the new node will not be locked. This could cause problems with DNS records if the source cluster nodes are rebooted or the resources are otherwise cycled on the new owning node. This issue may be resolved in a future release.
  1. When you first open the Double-Take Console, the Home page may not show any jobs in an error state. If you go to any other page in the console and then return to the Home page, any jobs with errors will be displayed. This issue may be resolved in a future release.
  1. If you are using Trend Micro Firewall, shares may not be accessible after failover. You can work around this issue by resetting the NIC’s IP address with the netsh ip reset command. For more details on using this command, see your Windows reference.
  1. If you are protecting a Hyper-V source and you select an existing Hyper-V server to use as the target, the Hyper-V Integration Services on the target must be version 2008 SP2 or greater. Without this version, the target may not start after failover. This limitation may be addressed in a future release.
  1. Because Windows 64-bit has a strict driver signing policy, if you get a stop code 0x7b after failover, you may have drivers failing to load because the driver signatures are failing the policy. In this case, reboot the server and press F8. Choose the option to not enforce the driver signing policy. If this allows the system to boot, then the problem is being caused by the cat file signature mismatch. This issue may be resolved in a future release. If your system still fails to boot, contact technical support.
  1. If you receive a path transformation error during job validation indicating a volume does not exist on the target server, even though there is no corresponding data being protected on the source, you will need to manually modify your replication rules. Go back to the Choose Data page and under the Replication Rules, locate the volume from the error message. Remove any rules associated with that volume. Complete the rest of the workflow and the validation should pass. This issue may be resolved in a future release.
  1. If you have specified replication rules that exclude a volume at the root, that volume will be incorrectly added as an inclusion if you edit the job after it has been established. If you need to edit your job, modify the replication rules to make sure they include the proper inclusion and exclusion rules that you want. This issue may be resolved in a future release.
  1. If you are using Double-Take over a WAN and do not have DNS name resolution, you will need to add the host names to the local host file on each server running Double-Take. See your Windows documentation for instructions on adding entries to host files.
  1. If you are running the Double-Take Console on a Windows XP machine and are inserting a Windows 2012 cluster into the console, you must use the IPv4 address to insert the cluster. The console will be unable to connect to the Double-Take Management Service on a Windows 2012 cluster if it is inserted using the name or fully-qualified domain name .
  1. If you are protecting a CSV volume on a Windows 2012 server, you may see event 16400 in the system log during a file rename operation. This error does not indicate a problem with replication or with data integrity on the target and can be ignored. This issue may be resolved in a future release.
  1. Service monitoring has been expanded to files and folders job, however, you must make sure that you are using the latest console. Older consoles will not be able to update service monitoring for upgraded servers, even for application jobs that had the service monitoring feature previously.
  1. If you are using a DNS reverse lookup zone , then it must be Active Directory integrated. Double-Take is unable to determine if this integration exists and therefore cannot warn you during job creation if it doesn’t exist.
  1. The Double-Take Management Service was not cluster-aware until version 6.0. Therefore, if you are monitoring clusters or cluster nodes that are running Double-Take 5.3 from a Double-Take Console that is running version 6.0 or later, you will see errors related to your servers. This does not impact the Manage Jobs page of the console and any jobs that may be using these clusters or cluster nodes.