Cloud BC/DR: 4 Questions to Gain Executive Buy-In

By Marc Goroff, Co-Founder and CTO, Quorum

It’s no longer enough to sell customer IT teams on the concept of moving services to the cloud, and then spinning up your preferred solution. IT leaders are doing online research before bringing you into the buying journey, and they are involving more line-of-business people in the decision-making process.

Or, in some cases, LOB leaders are involving themselves.

The good news for partners selling or consulting on BC/DR is that customers with legacy business-continuity and disaster-recovery plans and systems are likely facing challenges. Maybe it’s speed. Maybe it’s security. Maybe the system isn’t growing along with the organization.

When customers have other workloads in the cloud, virtualizing their BC/DR is an easier sell. They get the appeal of benefits like scalability, easier testing, and often, cost savings.They know cloud backups can protect data, servers, endpoints and applications. However, cloud-shy CIOs and IT managers may question whether moving BC/DR to the cloud in an as-a-service model is a good idea for their companies.

Here are four questions to focus the conversation.

How long are you willing to be down? In the era of 24/7 uptime, even 20 minutes of downtime can alienate end customers. Complex failover processes hinder recovery. When physical backups can’t be retrieved quickly, that 20-minute delay can be much longer. If uptime depends on the availability of trained staff or a shipment of backup tapes, mission-critical systems won’t be available when needed.

A major value proposition for moving to the cloud should be the capability to boot up a clone of the environment in minutes. This eliminates the need to ship or retrieve physical backups. Some cloud solutions also feature simple failover processes, allowing the IT team to recover instantly and enable employees to work from anywhere instead of reading complicated instructions as crucial minutes tick away.

Do you have the right connectivity? While cloud solutions can accelerate recovery, they can also hinder it in some situations, as when there is inadequate connectivity. Before advising that customers make the jump to a cloud-only solution, consider these possible delay factors:

How will available bandwidth affect retrieval speeds? Getting customer data into the cloud is easy — just identify …

… the servers and data to replicate, begin the sync, and off you go. However, keep in mind what you’ll be able to recover and what it could cost in terms of ingress/egress charges for data transfer.

While any modern LAN-based backup technology will perform file-level restores at 1 GB, cloud-based, file-level restores will rely on the site’s internet connection and the ISP’s bandwidth. If you have a 1 TB volume to restore, this is how long it could take:

That’s a big difference — and it will feel bigger if you’re trying to pull a customer back from a ransomware attack or other disaster.

Do you have all the information to calculate ROI? When IT teams evaluate BC/DR solutions, they tend to calculate the savings realized by eliminating downtime. Automated testing and other features can improve operational efficiency, and backup encryption and improved security can reduce risk. Yet too often teams don’t get that full pricing picture. Remember to factor in costs for external appliances, firewalls, switches and other network hardware critical to the BC/DR ecosystem. Any production environment will have unique backup needs that go beyond the suppliers’ standard offering. If you don’t account for those requirements and costs up front, the customer could be surprised by hidden costs that surface in the months following the initial cloud deployment. Make sure your suppliers provide transparent and predictable DR pricing that you can pass along.

Cloud BC/DR can offer speed and security when used in conjunction with other tools, such as a hybrid cloud solution. Keep the above four questions in mind and you’ll be more likely to get executive buy-in.

Marc Goroff is co-founder and chief technology officer at Quorum. Prior to co-founding Quorum, Marc was the head of software development at Sandpiper Networks where he led the team that created the internet’s first content delivery network. Prior to Sandpiper, Marc co-founded several successful software startups.