If you’re assessing Azure for your Disaster Recovery (DR), you’ll likely be looking to reap the benefits of eradicating expensive DR sites, pay-as-you-go pricing, unlimited scalability with immediate deployment and global coverage. Azure allows you to flex and scale your DR without limitation to keep up with your production site, whilst saving costs. It future proofs your DR, enabling you to keep your data anywhere in the world. In fact, there are a whole heap of desirable features and benefits that make Azure a highly attractive strategical option over expensive DR sites.

However, as with all great things, there are challenges. With Azure, it’s the migration challenge of getting your production systems Azure-ready in order that your DR system works with a minimum of hassle. Taking your production system from its current state and making it work on the Azure cloud isn’t as easy as it may seem. It’s far from easy in fact. Before you get too excited, look beyond the hype and take time to consider whether Azure is the correct investment for you or not.

Can you overcome the challenges of Azure?

With Azure, no amount of planning and preparation will guarantee that your migration will be fast and easy. The truth? It’s likely to be laborious and problematic. It’s only once you start the migration to Azure that you will know for certain how difficult it is going to be and, indeed, whether the benefits justify the means. The configuration of different servers, applications and networking will be unique to you. So, depending on which data centre/s you opt for, there could be differences in the migration pathways.

With Azure, you’ll need to audit your production infrastructure and identify all actions and changes required to make it Azure compatible, note that any existing Azure accounts may have implications on your DR project. Azure adjustments will need to be completed on your production system, as well as file adjustments, Azure set-up (including communications and network relays), and DR set-up; for example if using Zerto as your replication tool then you’ll need to go through Zerto Virtual Manager (ZVM) set-up. Depending on what technologies and testing you require, you may have other components to configure also. Ultimately, it will be your knowledge, experience, time and patience that will see you through the process.

Cost is a big factor when considering a move to Azure so let us explore in greater depth. There was a 20% increase in Azure pricing in February 2017, and as with all pay-as-you-use services, your DR costs aren’t fixed making it hard to manage your DR budget. There is a real danger that the costs associated with Azure can get out of hand. Whatever replication tool you choose (ASR or Zerto) then it’s likely that you’ll need to invest in Microsoft System Center Virtual Machine Manager (SCVMM). Furthermore, with every DR test carried out you will need to create a virtual machine in Azure prior to performing a failover – this incurs additional cost. It can be very easy to see storage costs soar with Azure. How can you keep Azure costs from escalating uncontrollably whilst maintaining a risk-free DR solution?

If you decide that Azure is right for your organisation from a strategic point of view then there are also functionality considerations; which replication technology offers you the best functionality? How well does this work with Azure? How do you test your DR? What RTOs and RPOs are achievable? How will you manage and maintain your DR etc?

When it comes to replication technologies it is important to understand their features and limitations. Azure Site Recovery (ASR) is specific to Azure, as opposed to others that will work with Amazon Web Services (AWS) as well as other private cloud environments. ASR works with Hyper-V, VMWare and physical servers, enabling it to replicate hybrid environments as opposed to just virtualised ones. However, ASR can be difficult from a user perspective. For example, in complex environments, automation runbooks are available for configuration tasks such as opening specific ports for remote desktop access or for Web access, but these require user experience of PowerShell.

The fact that configuration is required means that ASR isn’t capable of immediate failover, nor is failover fully orchestrated. ASR can also add complications to your production environment; for example, it is known to impact VMWare performance. Failback with ASR involves a migration project which can prevent businesses from failover thereby extending recovery times. When it comes down to it, DR testing with ASR can be difficult and therefore often not carried out. This can lead to many businesses using ASR without adequate protection against downtime - certainly not reaping the benefits of Azure.

Zerto’s latest 5.5 release enables not only fully orchestrated failover, but now also fully orchestrates failback, meaning businesses can push the button on failover a lot more easily, without the migration implications of failback. This addition allows businesses to now utilise their DR systems much more freely; in effect as a second set of production systems or as a highly efficient testing platform. It also promotes faster recovery of business-critical systems. Zerto however, cannot replicate physical servers, so an alternative method of replication must be sought for physical servers in those companies who operate hybrid environments.

For the time being it would seem that larger companies are exploring the benefits of Azure due to its infinite capacity and cost savings (these can also be harnessed by smaller companies). As a cautionary note – obtaining help from an organisation that knows how to get your DR Azure-ready could be a worthwhile investment in order to avoid the stressful and lengthy implementation experience of going it alone.

Ian Daly is director of Plan B Disaster Recovery