Business Continuity and Escrow Alternatives for SaaS Providers and Customers

I’ve always been skeptical of the value of source code escrow in the world of traditional installed software, and I’m clearly not the only one with that view. See this article from, Source Code Escrow: Are You Just Following the Herd?, in which the author states “Customers should be skeptical of expending valuable time and money on an arrangement that is largely ineffective at accomplishing the very purpose for which it was created.” Other writers with experience in this area have stated that they’ve never seen a customer successfully get source code out of escrow and be able to use it.

However, when traditional software is installed and running on servers under the control of the customer, even if the software provider is no longer around, the likelihood is that the customer will be able to continue running the software even if the customer isn’t able to access and use the source code.

The situation is completely different for applications hosted by the software provider. In the SaaS world, a problem with the application provider could leave a customer with no access to the application and, even worse, no way to access its data stored on the provider’s system. There’s a good discussion of these issues here, SaaS contingency plans need more than software escrow, and here, Business Continuity with SaaS.

With  more companies using applications in the cloud, the traditional escrow companies like Iron Mountain and EscrowTech have developed services designed for the SaaS world, including not only source code escrow, but also data escrow and business continuity options. E.g., from Iron Mountain, SaaSProtect Continuity Services, and from EscrowTech, SaaS Escrow. In theory it seems that these business continuity services are more likely to provide value to the customer than traditional source code escrow. Under the most robust (and expensive) business continuity options, the escrow company will be running a parallel system with up-to-date code and data that can be up and running almost immediately after a failure of the service provider or its systems.

This kind of business continuity service makes much more sense than an escrow of source code. If a SaaS customer has assurance that, no matter what happens to the SaaS provider, the customer will have almost immediate access to a running system with current data (with the possible exception of bankruptcy concerns), it should be in nearly the same situation it would be in if it were running the system on its own servers.

What I question is why should SaaS providers or their customers have to pay an escrow service for this kind of business continuity service? Most SaaS providers are not running their own data centers. They’re running their applications on the systems of a third-party hosting provider like Amazon Web Services or one of the many other hosting providers that are out there. These hosting providers are perfectly capable of providing backups of code and data, mirrored systems, or whatever other business continuity arrangements the escrow companies are providing. In fact, in most cases they are probably already doing many of these things as part of their normal hosting services. So why would anyone need to pay a third-party escrow service to do something the hosting company should be able to do better and at a lower cost?

I’ve spent quite a bit of time researching this subject and I find it surprising how little I was able to find. T. van de Zante and S. Jansen discuss it in their paper, Business Continuity with SaaS: “The next step towards a more complete business continuity agreement would be an agreement with the hosting provider, in such a way that they ensure they will continue hosting the application even when the SaaS provider gets into financial difficulties.” And the UK escrow company LE&AS talks about an “Access Assure Escrow Agreement” they’ve developed that involves the software vendor, the software user, and the third-party hosting provider. But other than those two references I haven’t been able to find much on this subject.

As counsel to a SaaS provider I understand that our customers have a legitimate concern about business continuity, and we want to be able to provide them with a reliable, practical, and cost-effective solution that would allow them to continue to access the service and their data even if we go out of business or stop supporting the service. It seems that there should be a way to craft a three-party agreement with our customer and our hosting provider that would provide our customer with an escrow-like solution that doesn’t require a separate escrow service, that gives the customer a very robust business continuity solution, and that is at least as bankruptcy-proof as a traditional source-code escrow. If anyone has done this or tried to do it I’d be very interested in your experience, advice, sample agreements, hosting providers that offer this service, etc.


7 Responses to Business Continuity and Escrow Alternatives for SaaS Providers and Customers

  1. Alex says:

    David, good article.

    You had any feedback about the alternative you suggest, i.e. through hosting provider?


    • davidmunn says:


      Thanks for your interest. I really didn’t get any good answers. So I’m now working with the IT, Privacy, and Ecommerce Committee of the Association of Corporate Counsel (ACC) on this and hope to put together an article for their Docket magazine and/or a program for their 2015 annual meeting. So I’ll probably be looking into this more over the next few months.

      Software escrow is at least fairly well recognized for bankruptcy purposes, even if it generally doesn’t work as a practical matter. Having the hosting provider provide the business continuity solution seems like it could be a practical solution, but for it to be viable as a real business continuity solution someone will have to figure out how it would work in a bankruptcy/insolvency proceeding in different jurisdictions.


      • Alex says:

        Thanks for the reply David.

        Have a USA based customer that is asking for this.

        Not seeing well defined solution offerings. One would think that hosting companies would’ve seen the easy on-sell, operationally in any event.

  2. Mike says:

    Great article…I have recently shopped for a more practice SaaS bc/dr service with a similar outcome. Our hosting provider does not want to assume the responsibility of managing an application and the escrow agent will but with significant cost…both major vendors in the market.

    Have you considered addressing this by creating an entity specifically to provide failover services to the SaaS provider. The provider would maintain majority control and offer customers minority shares if they opt into the program. The provider purchases services from the entity to cover costs in maintaining the failover environment. The entity maintains a board including its customers and is diligent in it DR preparation. In the event similar to an escrow release condition, the providers ownership would be distributed to the customers leaving them in control. Meanwhile the service continues now under the control of the customer driven board. They determine time, whether to pay the new entity, or dissolve it as customers are able to find replacement services. Could be a few months or a few years, or theoretically they could fund the company indefinitely.

    I am not an attorney and would love to hear if there are any glaring holes and your thoughts in general in this approach.


  3. Len Green says:

    David…has that 2015 ACC booklet or meeting materialized? Thanks

  4. davidmunn says:

    Unfortunately the person I was hoping would work with me to put a program together (outside counsel sponsor of the ACC ITPEC Committee) seems to have lost interest in it. Not sure why. I would like to get their help in figuring out the legal and bankruptcy implications in different jurisdictions. So the answer is no. I was never able to put this together. The issue hasn’t come up in my practice recently so I haven’t spent much time on it to see if there’s anything new that might address the issue.

Leave a Reply to Alex Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: