SaaS escrow

In the traditional sale of on-premises software are contract provisions about the in escrow giving the source code has become fairly standard. Today, cloud applications, including software-as-a-service (SaaS) solutions, however, are increasingly taking the place of on-premises software adopted.

With SaaS, the customer is often at greater risk of losing access to the application than with traditional software. The traditional source code escrow-model is usually not enough to mitigate that risk. Saas customers are therefore increasingly demanding that SaaS applications also have a escrow solution is proposed : the SaaS escrow matches.

How does such a SaaS work escrow agreement and how are risks and costs shared between the parties?

To understand this new escrow model, one must first understand the traditional on-premises escrow-model to understand. Escrow of source code provides buyers with a contingency plan in case the software vendor goes out of business or can no longer provide maintenance and support for the software.

When a company becomes dependent on certain software to continue its operations, a escrow-provision for source code in the software license agreement (and a separate tripartite escrow-source code agreement between the customer, the software vendor and a escrow agent) an essential safety net for business continuity. The existence of escrow has become so common that software vendors are increasingly including it as standard in their agreements. This leads to smoother negotiations and also builds customer confidence.

On-premises software works in its own live environment of the customer. The customer's data is stored on its internal systems and backup systems. Therefore, the availability of the software depends on the availability of the customer's own system. In general, if the software vendor decides to stop further development of the software, goes out of business or ceases operations, this often creates few problems for the customer because the software can continue to run on the customer's system.

In such cases, the client will then invoke its rights under traditional source code escrow-agreement. On this basis, he will have access to the source code and development environment to redevelop the software (or have it developed by another service provider), allowing him to continue to use, maintain and update the software with little or no downtime.

Because there is little or no threat of immediate, substantial business interruption, traditional escrow-source code agreements often include the condition that the source code be provided by the escrow agent may be released only if a certain time has elapsed (for example, the software vendor must have ceased operations for a period of 60 days or more).

With SaaS, on the other hand, the software code, infrastructure, data and storage are located in a production environment outside the customer's premises. The availability of the software often depends not only on the SaaS service provider, but also on its external hosting/cloud providers. Data failures and inaccessibility, even if they last only a few minutes, can result in significant business interruption for the customer. In such a scenario, a traditional source code has escrow-agreement little or no use to the customer.

The customer therefore has a much wider range of escrow services needed to help him in the event of an outage, including a copy of his data stored in a secure backup data center, backup hosting, very detailed documentation with build instructions for recreating (or engaging an outside vendor for recreating) the application and the production environment, and of course the source code and object code.

To address these needs, source code vendors offer escrow services now also offers SaaS risk management services. This escrow-vendors have created programs to ensure SaaS application continuity and data accessibility. For example, they allow the SaaS application (and all the customer's data) to be copied to a second server in a secure data center and can even host a standby recovery environment on which the application can continue to run seamlessly in the case of mission-critical applications where the customer doesn't even afford a few minutes downtime can afford.

Although SaaS service providers have often initially resisted including escrow-provisions in SaaS license agreements, there seems to be a recent shift in this. Indeed, SaaS service providers initially took the position that they did not need to provide continuity guarantees and relied on business continuity and disaster recovery policies to reassure customers (even though these business continuity and disaster recovery policies often apply to the SaaS service provider's business and not the customer's).

However, as companies become more knowledgeable about cloud solutions and more experienced in deploying SaaS applications, we are seeing more and more demand for SaaS in practice escrow-provisions in SaaS license agreements.

How to negotiate a SaaS escrow?

There are many things to consider when negotiating escrow-provisions for SaaS. The extent of what is given in escrow is an important issue because the customer wants what is in escrow is given contains everything necessary to reproduce the development environment and run the application. Often it is not clear exactly what this means. The details that a SaaS service provider must provide in its documentation to allow the customer or a third party to run the executable code (executable code) to recompile can be much more than what the SaaS service provider typically states in its customer documentation, which can result in additional costs for the SaaS service provider.

In some cases, to fully port the solution to another environment, the customer may need access to additional third-party software or data sources that support the SaaS application. Here, SaaS service provider should consider whether they have received the necessary permissions from these third parties to do all of this in escrow place.

Customers often want to use escrow service providers those mirrored (mirrored) applications can be maintained and immediately activated and hosted by the escrow agent, the customer or the customer's external service provider. In effect, these serve as a business continuity site. Such escrow-solutions can be expensive, making the issue of cost allocation another point of negotiation with SaaS escrow-clauses.

In addition, one of the biggest points of contention between Saas service provider and customers is the escrow release conditions. As discussed above, in the traditional software model, release of source code generally requires the software vendor to cease all operations for a significant period of time (e.g., 30-60 days), file for bankruptcy or be in other proceedings related to insolvency or liquidation, or officially stop developing the software and/or supporting it.

Regarding the SaaS escrow-model, sensible customers understand the need for release conditions that reflect the urgency of downtime can address. SaaS service provider, however, do not want to release their applications and the intellectual property rights associated with them so easily.

Therefore, the release terms for SaaS escrow often match the applicable service-level agreements. If an SLA provides reasonable solutions for short periods of unscheduled downtime, then the SaaS vendor can argue that the escrow should be activated only during extended periods of unscheduled downtime or recurring failures.

Although there are several points about this SaaS escrow-provisions can be negotiated, SaaS service providers are increasingly accepting the presence of SaaS escrow and include them in their licensing requirements to convince potential customers wary of business continuity risks.

From the customer's standpoint, it is necessary to assess (1) whether the application is mission-critical; (2) what the cost is both financially and in terms of reputational damage; (3) the availability of replacement applications; (4) the transition time to a replacement application; and (5) the stability and reliability of the software vendor.

Even though SaaS escrow provisions increasingly common in SaaS agreements, the question remains whether they are effective. A escrow may reassure the customer at the time that it assesses the risks in entering into a SaaS agreement, but the actual practical transition of the application, data center and hosting environment in the event to the escrow release conditions are met can sometimes be more disastrous than the downtime themselves. It is therefore important to establish solid Saas escrow agreements that cover all risks.

Contact

Questions? Need advice?
Contact Attorney Joris Deene.

Phone: 09/280.20.68
E-mail: joris.deene@everest-law.be

Topics