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 CIO.com, 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.
Posted by davidmunn 
David Munn's Legaltech Blog 