Don't Build a DR Site At All

For many years now, organizations have built massive IT operations around delivering the technology services their staff and clients need. But recently, there’s been a growing trend of “x-as-a-Service” adoption that allows IT leaders to deliver the same value without the overhead and expense of procuring, deploying, operating, and maintaining the infrastructure and software necessary to provide such a service.

A prime example is email. A decade ago, most businesses ran Microsoft Exchange on a physical server in their server room. Today, options like Microsoft Office 365 and G Suite by Google Cloud offer the same—or better—messaging capabilities via a Software-as-a-Service (SaaS) model. The consumer gets everything they need (email and surrounding features) without all the stuff they don’t need (data center infrastructure, a dedicated Exchange administrator, software support agreements, and so on).

In this new decade, the same paradigm applies to DR. Just like the overhead and inefficiency of running your own messaging infrastructure is almost laughable today, building and maintaining a full DR site that’s propped up by overcomplicated orchestration software is a hopelessly outdated tactic.

Instead, consider adopting a modern approach where DR orchestration is consumed in a SaaS model, and DR infrastructure is only instantiated when it’s needed.


Standby data centers are often likened to an insurance policy. They exist for use during a disaster, and only in the event of a disaster. Compared to an on-demand DR site, the costs of maintaining a dedicated DR site are staggering. Consider the following two hypothetical scenarios: Assume that each business needs to activate their DR plan this year and failover to their DR site.

Business A

Pays multiple six figures per year for facilities, hardware, software, and man hours to deploy and maintain a secondary data center. In the case of a disaster, they pay a few thousand dollars in professional services fees to get hands-on help from their service provider at the colocation facility where their DR site is housed.

Business B

Pays a small fee per year for a software subscription for DR orchestration and the associated storage capacity for backup data. In the event a failover takes place, they pay via consumption-based billing for the computing resources they used, and only for the duration of the outage.

Figure 1 uses the insurance analogy to compare the two scenarios in an easy-to-understand table. While the dedicated DR site has predictably high cost year-round, the on-demand DR site only incurs significant expense during an actual DR event.

The reason progressive organizations love public cloud is because they only pay for what they use, right? Why shouldn’t DR be the same way?

Figure 1: A simple cost illustration showing a dedicated, warm DR site and orchestration versus an on-demand DR site with SaaS DR orchestration


For this new decade, consider whether operating a secondary data center and maintaining and testing complex DR orchestration software is really a business you want to be in. Or perhaps you’d be better served by a SaaS orchestration model and on-demand DR service that’s economically and operationally superior.