One of the most popular sales inquiries our team fields is related to the desire to build a DR site for a SaaS or IT application. However, despite the popularity of this question, very few clients follow through with implementing a true disaster recovery solution due to the costs complexities involved.
Over the last few years, we’ve been through hundreds of these discussions with clients, and we’ve seen our clients waste a lot of time developing solutions that are never implemented. Through these conversations, we have learned a lot about which situations are likely to result in a DR implementation and which will condemn a client to live perpetually in the “we should implement DR” phase.
If you find that the four “signs” below describe your application at your company, we advise that you ask the hard questions internally before spending the time designing a DR solution that is unlikely to be implemented.
So, without further ado, below are four signs your SaaS application is not ready for DR.
One: You don’t launch missiles or fly airplanes
This one is simple. If your application isn’t involved in national defense, coordinating mass transit, or some other “can’t ever fail without causing someone bodily harm” computing system, it is far less likely that DR is required to sell your product (don’t let your sales team convince you otherwise without more research). It’s important to keep perspective here. While it might seem like your clients can’t live without your product for a few hours, very few applications really fall into this category.
Two: You haven’t implemented local redundancy
This is another relatively straight-forward piece of advice, but one we often see clients mis-prioritize. If your production site is not capable of load balancing and fault tolerance at the web, application, and database tiers, you are much better off investing additional budget in local site redundancy before adding the complexity and costs of multi-site failover. Local site failover is less expensive than multi-site DR, and also more likely to be needed. Please start here before pursuing grander DR designs.
Three: You Haven’t Hit Critical Mass
Until your number of active (paying) clients is significant, adding the costs of DR and sharing it across a small number of clients is normally completely undoable for early to mid-stage companies.
One of the first qualifying questions we discuss with clients is whether their board is supportive of cutting margins in half to allow them to implement DR. While it is definitely possible to implement disaster recovery without doubling COGs, for most applications the minimum cost to implement a legitimate DR solution is a 35% increase of the current production site run rate. The average incremental cost of DR ranges from 60-70% of the production site cost, and both of these estimates are before calculating the costs of additional staff or operational complexities that come with maintaining two sites simultaneously, which are also non-trivial.
While many new DR products promise to cut the costs of traditional DR drastically, and the use of dynamic Cloud resources also can limit the costs of DR infrastructure, the reality is that proper DR is still quite expensive to do properly. Additionally, the way many applications are coded makes it difficult to take advantage of newly developed “cloud only” DR solutions. If your company isn’t ready to accept the decreased margins from implementing DR, save yourself a long discovery process and secure this internal commitment before you design the solution.
Four: Your customers won’t pay for it
Closely related to the previous point, if your customers won’t pay for the added benefit of having a second site, it is unlikely that you will implement a second site for DR.
One tip we share with our clients is to position DR as an “add on” solution. We’ve observed a very interesting dichotomy when joint-selling with our clients whose applications we help deliver (which we often do).
- Clients who answer “No” to the “Do you have DR?” question occasionally are excluded from opportunities in the RFP phase based on this checkbox evaluation by their prospects.
- Clients whose products have even very limited DR capability, but offer it as a paid upgrade (usually an expensive one) are able to exclude DR from the requirements in nearly every sales cycle.
The reason behind this behavior typically ties back to the security or risk officer in the prospective buyer’s organization. The risk officer must wave the red flag and identify the risk of any vendor not offering DR. In the absence of any strong answer to that challenge, vendors can be excluded on that basis alone.
However, the game changes considerably when a vendor is able to respond to the risk officer with a paid upgrade for DR. In a typical scenario, our clients position DR as a paid upgrade that adds 50-100% of the cost of a single site solution. At this point, the risk officer is able to claim that he or she has identified the risk to the business, and that the commercial decision is up to the business unit (BU) purchasing the service to determine whether lowering the risk is worth the additional cost.
In most cases, the BU will not be willing to pay the cost of DR, and the sale closes successfully with a single site solution. Another common fallback scenario in the absence of a full DR solution is to commit to backup all client data offsite, which can be done quite cost-affordably and usually greatly increase the risk officer’s comfort level as well.
If you do not have a strategy like this for your SaaS product, and assuming all of your competitors do not offer a multi-site solution for free, take my word for it that your sales team will thank you for implementing a product & pricing strategy along these lines.
If you have questions about your own DR strategy, drop me a comment on this post.