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?
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.
There are also several limitations to what Azure Site Recovery can currently handle:
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:
Two additional scenarios that are supported for migrations only are:
In all of these cases, the steps for setting up migration are very similar:
Each of the scenarios has its subtle nuances, but understanding these general steps will help with filling in those specific pieces later.
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 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.