1) Azure Site Recovery (ASR)
This is the default solution from Microsoft to replicate and orchestrate failover in the Azure cloud. You can replicate the running VMs from different servers to Azure. ASR supports source servers in Hyper-V, VMware, AWS, Linux, and SQL Server. The Azure cloud environment becomes a disaster recovery center, while offering orchestration and business failover.
Moving the VMs to Azure happens in the background while the VMs are running. Now, you can also set up an orchestration in ASR to deploy the VMs in a custom order based on their data dependencies and application services. Further, you can also perform a test failover to check if the services are functioning as usual. Any necessary changes to the VMs can be made meanwhile, and then the failover can resume. Changes can also include modifications to the Azure virtual network mapping. Below are the processes involved in the failover mechanism.
- Shutting down of all replicated on-premises VMs
- If any data is not replicated, then it is flushed to Azure and the replica VMs are updated
- The VMs are finally deployed in Azure according to the pre-defined order
This method results in minimum downtime, probably in seconds to a few minutes. The downtime is based on the Azure environment size.
Pros: Negligible downtime. The small amount of downtime enables consistency in the asynchronous replication, in case of latent network connections. This kind of VM migration also allows the opportunity to test before making the move.
Cons: You need to have a disaster recovery solution before moving VMs to the cloud. Your on-premises servers needs to be installed with System Center Virtual Machine Manager to manage the server farm. This is a considerable expense that many small businesses cannot afford. Also, the per-VM monthly cost adds to the total cost while implementing the replication.
2) Microsoft Virtual Machine Converter 3.0
This tool can convert vSphere VMs into Azure compatible Virtual Hard Disks (VHDs) while moving them to Azure. It offers a simpler GUI for a smaller migrations. You can leverage the PowerShell framework for larger migrations. They are pretty much self-service migrations combined with the System Center Service Manager.
Pros: A free tool with the advantage of PowerShell. It is pitch-perfect for orchestration and self-service.
Cons: Limited to vSphere.
3) Uploading VHDs manually
Microsoft Azure supports uploading Virtual Hard Disks (VHDs). But you should keep in mind that Azure supports only Hyper-V Generation 1 VMs with VHD format disks. First, you need to prepare the target OS using Sysprep tool, and then you can upload a VHD to the target OS. You can then create the disk image that can be easily accessed for further deployments. By creating an application server, you need multiple instances of this VM to quickly deliver services.
You can also apply the above method to your current VMs. You don’t need to generalize these VMs, but you can prepare the guest OS. Then, you can configure the VMs. Now, you can shut down your production VM and upload the VHDs to a storage account in Azure. Remember to upload only the hard disks only in VHD format. If you are going to choose VHDX files, then you should convert them to VHD format. The disks would be readily available to create an Azure VM, and you can also reuse your on-premises storage. This enables you to get a near-similar copy of the VM on the Azure cloud.
Pros: This method doesn’t include any additional costs apart from regular Azure subscription.
Cons: Lots of manual work required. High chances of errors. A huge downtime by the conventional upload of virtual hard disks.
Migrating your workloads to the cloud platform across a latent network is not easy. But with the right tools and IT help, you can plan appropriately to lower the downtime to business systems. We at Deevita are your trusted Azure partner along the cloud journey. Request a demo today to know how we can help you achieve business intelligence with Azure on your side.