Contract Corner: SaaS Escrow Considerations (Part 1)
With software as a service (SaaS) offerings here to stay as the preferred technology solution for many key business requirements, we are seeing more and more requests for escrow arrangements involving SaaS solutions.
We’ve discussed source code escrow agreements in a previous two-part series (see Part 1 and Part 2). Like escrows involved in other license deals, SaaS escrows are often appropriate where customers are concerned about business disruption if the vendor goes out of business or otherwise stops supporting the software, and vendors remain reluctant to make their proprietary source code available to third parties.
Part 1 of this two-part series outlines some unique issues for escrow arrangements in the SaaS context and highlights related customer and vendor considerations.
Scope of SaaS Escrow Arrangements
In license deals for installed software, the scope of the escrow materials is generally limited to the source code for the particular licensed software and any related documentation necessary to allow the customer to ensure continued maintenance and support of the software by providing those services itself. In contrast, in license deals involving hosted applications, the scope of the escrow must be broader in order to allow the customer to assume responsibility for hosting the solution in addition to the related maintenance and support. For this reason, the scope of the escrow typically includes the source code and object code of the underlying software, any ancillary software necessary to operate and maintain the underlying software, and any related documentation.
From the customer side, it is important to ensure that you have a sufficient understanding of what is necessary to provide the software so that you can adequately define the scope of the escrow materials in the contract. While the nature of SaaS solutions makes it inherently difficult for a customer to simply step into the vendor’s shoes and begin hosting and providing the software upon the occurrence of a release event (even where the correct materials are included in the escrow), this difficulty can become an impossibility if the escrow materials do not include all of the requisite technology.
From the vendor side, it is important that the definition of the escrow materials isn’t overly broad in such a way that commits the vendor to placing materials in escrow that it does not in fact possess. An example of this type of broad escrow materials requirement would be any requirement that all ancillary software in escrow includes detailed, complete documentation that would allow any programmer with no experience with the underlying licensed software to host and make modifications to such software, where that level of detailed documentation does not exist within the vendor’s organization. In this situation, aside from attempting to negotiate a narrower scope of escrow materials, the vendor should consider whether it is in fact unable to produce the requisite documentation or, if the requisite documentation could be produced, if it would be an expensive and time consuming task that the vendor is not willing to undertake. In the latter situation, the vendor may be able to agree to the broader scope of escrow materials if the customer is willing to share the cost of or otherwise provide economic incentives for the vendor to develop any additional materials that the customer is requiring to be escrowed.