Azure Site Recovery (ASR) limitations which are difficult to bypass

Recently I have seen issues with the limitation of Azure Site Recovery and tried multiple ways to get it passed, later it became a road block to use ASR for migration of the large Oracle database servers. Here are the two major limitations of ASR which I have faced.

1. ASR doesn’t support clustered disks.
2. ASR doesn’t support GPT/UEFI disk (In OS Disks)

Now most of the enterprise will have clustered disks, so the workaround for the above problem is to disable cluster services, and create stand-alone VM’s. And consider standalone servers for the migration, which may not work for many lift and shift type migration strategies of large databases and other workloads.

Also the conversion of GPT to MBR disk will also not work here because these disks are mostly OS disks and there is no supported way to convert them to MBR partition.

We thought for a workaround to create a VHDX using disk2VHD (GPT disk) and then create a Gen2 VM on Hyper-V, thinking that ASR will work in this case, however we have found that 2008 R2 isn’t supported as a Generation2 VM, so we not able to proceed further on this unless we upgrade the OS which is no go from the application owners.

So if you are planning to move physical boxes or VM’s which have GPT partitions in the C drive OR have the clustered disks, it’s may be better to look out for some different tool for the migration instead of using ASR at this point of time.

When we look out of this with the 3rd party I came across with a vendor called doubletake and  when we have checked their cloud migration user guide and we do not see comments specific to UEFI partition based Windows machines.

Here is the user guide for doubletake your reference.

https://migrate.doubletake.com/docs/CMCUsersGuide.pdf

It says it does not support UEFI disks on Linux machines. Nothing on Windows 🙂

For more details on Azure Site Recovery Support Matrix, please check this link

Bottom line is that ASR may be a very good tool but has few limitations and if you are planning for large scale migration with different workloads, you need to plan for your large workload sprint in advance and need to decide the strategy as a case to case basis.