Companies running their businesses on cloud platforms are increasingly relying on escrow policies to ensure they can keep operating if a mission-critical software-as-a-service (SaaS) vendor goes bankrupt or its platform goes down. But how seamlessly these policies can be turned into a practical solution remains a question, since replicating operations requires more than just having the source code available.
“While the escrow can give customers comfort when taking on the risk of onboarding a SaaS solution, the actual, practical transitioning of the application, data center and hosting environment in the event of a release condition may be more catastrophic than the downtime itself,” Mark Kesslen and Leah Satlin, attorneys with Lowenstein Sandler, say in a Law360 article.
Software escrow policies have been around for decades, but the products were initially designed for on-premises software and only in recent years has the industry shifted its focus to SaaS products in a big way.
Based on data it’s compiled, Advance Market Analytics says the global market for software escrow services is booming, “mainly driven by the increasing R&D spending across the world.”
By some estimates, 95% of new software will be cloud-based by 2025, highlighting the need for escrow policies to work well in an off-site environment, but SaaS companies until recently have hesitated to include policies in their subscription agreements with customers.
“The tide appears to be turning,” Kesslen and Satlin say. “Businesses are becoming more sophisticated about cloud solutions, and more experienced in onboarding SaaS applications, [so] we are seeing more demand for SaaS escrow provisions in subscription agreements.”
It’s more complicated to make escrow policies work in a cloud environment because all of the operational pieces – the software code, the infrastructure, the data and storage – are hosted in a production environment outside of the customer’s premises, often involving more than one company: the SaaS provider and the third-party hosting company like AWS, for example.
If the platform goes down, even for just a few minutes, the company loses control over its operations.
“In such a scenario, a traditional source code escrow agreement is of little or no use to the customer,” the attorneys say.
By contrast, maintaining operations during a disruption in an on-premises context is straight-forward, because the production environment is within the control of the company; if the software provider goes out of business or otherwise stops providing updates or other services, the company can continue to operate while it makes a claim to get access to the source code and what else it needs to maintain its operations for the long-term. The typical claim period is measured in months.
For general counsel considering SaaS escrow options, the stakes are high, because in addition to the source code, the company needs a copy of its data, a back-up hosting site and the build instructions for recreating the application and production environment.
In a positive development, SaaS escrow providers have started offering risk-management services that incorporate these broader needs into their products, Kesslen and Satlin say.
Under this broader approach, providers copy the SaaS application and customer data to a second server located at a secure data center, and in some cases host a standby recovery environment on which it can run the application temporarily if the hosting site goes down.
In an ideal case, the escrow service provider maintains mirrored applications that can be instantaneously activated if something goes wrong, but you can expect that kind of program to be expensive. That’s something GCs can raise if their company is shopping around for escrow services.
“The issue of cost allocation is [a] point of negotiation in SaaS escrow provisions as they become more prevalent in the market,” the attorneys say.
From a legal standpoint, escrow-release conditions can be tricky, because a company doesn’t have the luxury of time it has with on-premises software. If an online platform goes down, companies need to trigger their back-up arrangement immediately, but providers have to be careful about how they release their source code.
“Providers do not want to release their applications and all of the intellectual property … so easily,” they say. “SaaS escrow release conditions often dovetail with the applicable service-level agreements. If an SLA provides for reasonable remedies for short periods of unplanned downtime, then the SaaS provider can argue that the escrow should only be triggered by longer periods of unplanned downtime or chronic failures.”
In sum, there are many things to consider in negotiating SaaS escrow provisions.
GCs want to be sure the scope of the escrow materials includes everything necessary to reproduce the development environment and run the application. But providers might find it hard to provide that much information.
“The level of detail that providers may have to give in their documentation to enable the customer or a third party to recompile the executable code may be far above and beyond what the provider typically states in its customer-facing documentation,” Kesslen and Satlin say.
There are legal issues, too. “In some cases, to fully transition the solution to another environment, the customer may need access to third-party ancillary software or data sources that support the SaaS application, and providers must consider whether it is even within the provider’s rights or ability to place into escrow,” they say.
There’s a lot to think about, but if your company depends on cloud platforms to run its businesses, you want to do your due diligence to ensure you have an escrow policy that enables a seamless transition in a disruption.