Migrating Resources to Azure Using Site Recovery — Part 1

Published 11/12/2018 01:11 PM   |    Updated 05/16/2019 11:39 AM
As the pressure increases for companies to "cloud-enable" their business to remain competitive, IT managers are looking for the best way to get their workloads moved from on premises or co-located data centers to Azure.

Most companies start with a few individual servers and services to gain familiarity with the platform but still need a way to "lift and shift" their remaining workloads. Some use a combination of PowerShell and Azure Resource Manager templates to create the new infrastructure but are then tasked with the best way to migrate their existing data and configuration.

To migrate servers and data together with minimal downtime and impact to the business, a tool that does near-real-time replication is needed. That tool is Azure Site Recovery.

Primarily known as a tool for protecting servers in the event of a disaster, Azure Site Recovery can also be used to move servers to Azure with relative ease. And, with the right planning and preparation, it can essentially be done for free.

Microsoft allows up to 31 days of protection per server before charges begin. Simply put, if you can get a server fully migrated in 30 days or less, you’ll be charged nothing more than the cost of the storage for the data itself. That's tough to ignore.

So, how do we get started?

Step 1: Plan.

We've all heard the phrase, "Failing to plan is planning to fail" (paraphrased from Benjamin Franklin's original, "If you fail to plan, you are planning to fail.").

Although I don't think he had server migrations in mind when he coined the phrase, it definitely applies here. Setting up Azure Site Recovery and migrating the servers is fairly simple in the grand scheme of things, but if you don't plan ahead, it can be — and will be — a frustrating experience.

  • How should I structure my network?
    • How should I structure my network?
    • What workloads will be migrated?
    • How much bandwidth can I spare without impacting daily business?
    • Will I need to expand the infrastructure/implement high availability in the future?
  • What workloads will be migrated?
    • Domain controllers/Active Directory/DNS?
    • SQL Server? Application/web servers?
  • How much bandwidth can I spare without impacting daily business?
  • Will I need to expand the infrastructure/implement high availability in the future?

There are also several limitations to what Azure Site Recovery can currently handle:

  1. UEFI/EFI drives are not supported.
  2. iSCSI and FC disks are not supported.
  3. Static IP addresses on Linux servers are not supported.
  4. The servers must be running 64-bit operating systems of Windows 2008 or higher.
  5. Hostnames, mount points, device names and Windows system paths should be in English.
  6. The operating system should be installed on the C drive.
  7. Drive letter E is reserved in Azure. If you have servers to be migrated that have data on the E drive, then the drive letter needs to be changed prior to migration.
  8. Windows Server disks should be basic.
  9. Shared disks are not supported.
  10. Failover clusters are not supported.
  11. Administrator rights may be needed to deploy the Azure Agents.
  12. Azure Site Recovery supports premium storage for replicated data, but a standard storage account is still needed for logging purposes.
  13. All standard Azure limitations still apply.

Step 2: Migrate and test.

With the planning out of the way, we come to the fun part: setting up the migration.

Azure Site Recovery supports the following scenarios for replication:

  • Hyper-V to Azure
  • Hyper-V Virtual Machine Manager (VMM) to Azure
  • VMware to Azure
  • Physical servers to Azure (failback to VMware only)

Two additional scenarios that are supported for migrations only are:

  • Azure region to Azure region (failback is currently in preview)
  • Amazon Web Services (AWS) Windows instances to Azure Infrastructure as a Service (IaaS) virtual machines

In all of these cases, the steps for setting up migration are very similar:

  1. Create a Recovery Services vault.
  2. Create storage accounts to hold the replicated data before migration, and the server Virtual Hard Disks (VHDs) after.
  3. Configure the required servers needed for your migration (Hyper-V, VMware, VMM, etc.) and add them to the vault configuration.
  4. Specify replication settings.
  5. Enable replication for the servers you want to migrate.
  6. Do a test failover to verify the servers are working as expected.
  7. After multiple rounds of testing and adjustments, do a planned failover to recover the new VMs in Azure.
  8. Complete the migration for each server.

Each of the scenarios has its subtle nuances, but understanding these general steps will help with filling in those specific pieces later.

Step 3: Protect, monitor and improve.

Once your servers are migrated and working as expected, there’s still more work to be done.


First would be to make sure the original servers still on premises have been turned off to avoid any accidental network conflicts. You can then handle decommissioning them as needed.


Next would be to set up backup jobs for the migrated servers. Be sure to take a look at the Azure Backup service for this, which actually integrates with the Recovery Services vault you just created for migration.


Another recommendation is to set up server monitoring such as that provided by Operations Management Suite (OMS). You can do this by simply going to the Log Analytics blade in the Azure Portal, creating an OMS Workspace and having Azure inject the OMS agent into your virtual machines to begin the monitoring. Then you can view your system metrics using the OMS dashboard on your computer or mobile devices.

That's a wrap.

That should be enough to get you started on your path to migrating resources to Azure. You can also view the steps in more detail in our recorded webinar, where I give a high-level view into the supported workloads and how Azure Site Recovery works. Then I dive deeper and walk through some of the steps needed to get those workloads into Azure. I also explore the testing and validation process before finally completing the migration and shutting down the on-premise servers.
This article originally appeared on June 7, 2017.

Is this answer helpful?