When migrating to Azure, most companies want to simply move all their servers into Azure. Most of the time, this is a first step before migrating to other services, but for most servers it is the final destination.  So which way is the best to migrate whole servers into Azure?

Azure Site Recovery (ASR) is, without hesitation, the best tool for the job.  Although the name suggests it is a disaster recovery tool (it is), this handy system can also be used for migration, if you think of migration as a sync and then a permanent failover.

The wonderful thing about this system is how versatile it is; not only can you use it for Hyper-V, but VMWare is also supported, as well as physical machines.  While Azure only supports VHD files, ASR also supports and converts VHDX and VMDK files to a VHD file in Azure for you.  ASR also supports various Linux versions and distributions, too.

So how does it work?  There are two basic ways ASR operates, which are very different on the on-premises side, but treated the same in Azure:

  • If you are using Hyper-V, an agent is installed on each Hyper-V server, and data is copied into Azure directly from the Hyper-V machine.
  • If you are using VMWare or physical servers, an OVF template downloaded from Azure is required to create a VM. This VM contains a Configuration server (talks with Azure and manages data replication) and a Process server (receives replication data; optimizes it with caching, compression, and encryption; and sends it to Azure Storage), as well as a Master target server (handles replication data during failback from Azure).  Data is synced via this VM to Azure as soon as it is changed on the host machine.

In Azure, you can specify the VM name, size, VNet, IP Address, and storage accounts that the VM will use in Azure.  You can also enable managed disks and disk encryption, if needed.  While the servers are syncing, the only cost you have is the Storage Account space you are using, as nothing else is allocated yet.

There are a few items that require extra attention, such as a 4 TB disk size limit, encrypted disks on the source server that are not supported, as well as network limitations and various other limits depending on the operating system, VM environment and other configuration possibilities. As is normal with anything in Azure, it is better to check the documentation, as ASR is constantly improving.

Once the machine is fully synced with ASR (the amount of time it takes to fully sync with Azure will strongly depend on the speed of your internet connection), you can perform a test failover without shutting down the source machine to ensure the process will work and to give that extra piece of mind.  When you do perform the actual failover, the source machine is shutdown and the new one in Azure is brought up with the latest sync data and the specified settings, which normally takes about 5 minutes.  And if needed, more than one server can be migrated at the same time without an issue.

But what happens if the migration doesn’t go well?  Well, since ASR is primarily a disaster recovery tool, failing back to on-premise is also built into the tool, and is equally as easy.

Not bad for a full migration from on-premise to Azure for a complete server.