Tips and tricks: Ensuring business continuity - source code or cloud escrow?

Many companies are dependent on on-premise software or cloud solutions built and maintained by (external) suppliers. It is therefore not surprising that many want to ensure continuity of their activities and protect themselves against certain situations such as the insolvency or bankruptcy of the supplier or a material interruption in the supplier’s operations. This is particularly true when the on-premise software or cloud solution is business critical or when the supplier is a startup whose financial situation is uncertain. One of the options to consider is putting in place an escrow mechanism.

An escrow requires an agreement between the customer, the supplier and a neutral third-party escrow agent that sets out which material the escrow agent will store and which events trigger the release of this material to the customer. The customer and supplier can agree to enter into an escrow agreement from the start of their cooperation or to include in their main IT agreement an escrow clause that defines the key principles, ie describing the escrow material, the identity of the escrow agent, the trigger events, the license scope and the related practical arrangements. A future escrow agreement will then need to incorporate those principles.

Below we share some tips and tricks that can help to find an escrow mechanism that both customers and suppliers can agree on.

1. Source code or cloud escrow – Firstly, the parties will need to decide on the type of escrow. It is important to take into consideration whether on-premise software or a cloud solution is envisaged. For on-premise software, it is typically sufficient that the source code and related technical documentation is placed in escrow. In theory, this will enable the customer or replacement supplier to further maintain the software (eg fixing bugs, optimization of the solution, incident management). As the software and all relevant data is already hosted on the customer’s systems, problems on the supplier side will not always have an immediate impact on the customer’s day-to-day operations and may allow for remediation.
   
   For cloud solutions, which have become the new normal for many companies, a traditional source code escrow will often not be sufficient. As such solutions are hosted on the infrastructure of the supplier or a third-party cloud provider, there is a risk that, in case of insolvency or bankruptcy of the supplier, the solution will be down and unavailable for the customer. Even if a customer could access the underlying source code, it would not have any systems available and configured to run the solution. As a result of which, it may take the customer weeks if not months to set up an alternative IT infrastructure and rebuild the production environment. In addition, there is a real risk that the customer may lose the data stored in the cloud. To avoid such a scenario from happening, it could be interesting to consider a cloud escrow.
   
   Many escrow agents nowadays offer variants of cloud escrow. In practice we have observed the following main categories. The first category consists of placing the source code, detailed technical documentation on how the production environment needs to be built and an architectural overview of how the solution is hosted in escrow. This is intended for situations in which the solution (including the data) is hosted within customer’s public/private self-managed cloud infrastructure. The second category consists of placing the source code and the access credentials (eg passwords and keys) for the cloud environment in which the solution is stored in escrow. This is mainly relevant when the solution is hosted by a third-party cloud provider (eg Azure, AWS, Google Cloud Platform). In some cases, only the access credentials are placed in escrow. The third category entails the escrow agent setting up a separate hosted mirrored instance of the software solution and replicating all data. If the solution is hosted by the supplier, this will probably be the safest (and most costly) option for the customer.


2. Updates and upgrades – Secondly, it is important to ascertain that not only the version of the software solution that is current at a certain point in time (eg date of signature of the IT agreement or go-live) is placed in escrow but also all (major) updates and upgrades. The reason for this is that an escrow is only useful if the customer has the assurance that they can rely on a recent version of the on-premise software or cloud solution. For software or a solution that has a frequent release cycle, it could be an option to agree on quarterly updates with the escrow agent to limit costs.


3. Trigger events – Critical for the functioning of the escrow mechanism is that a clear list of events that trigger the release of the escrow material by the escrow agent is agreed on. The most common trigger event is the insolvency or bankruptcy of the supplier. In certain cases, it may be appropriate that the release of the escrow material can take place earlier. For example, when an action is taken against the supplier under any bankruptcy or insolvency laws or when the supplier’s turnover has decreased by more than a certain percentage. The customer may also wish to include trigger events that are linked to the supplier’s performance. Examples include the situation in which the supplier is in material breach of its (maintenance) obligations or created a material interruption in the services. However, other trigger events, such as a change of control or force majeure events, may also be considered, but may be more difficult to negotiate. As suppliers typically consider their software and intellectual property to be their crown jewels, they will try to limit the list of trigger events to what is strictly necessary.


4. License scope – In some cases the duration of the customer's license on the escrow material may be limited to the term of the IT agreement. Since the occurrence of a trigger event may coincide with the termination of the agreement, it is in both parties’ interest to clearly define the duration and scope of the customer’s license on the escrow material. The license will either be of perpetual duration or be limited to a number of months or the time necessary to find a replacement supplier. The scope of the license may include, in addition to the right to use the escrow material, the right to adapt and change the escrow material.


5. Costs – Finally, the parties need to agree on who will bear the costs of the escrow. It is not unusual that such costs are borne by the customer requesting the escrow or split in equal portions between customer and supplier. The situation is different if the supplier has already deposited its standard on-premise software or cloud solution in escrow and allows several customers to benefit from such existing escrow agreements. In such a case, it seems more appropriate that the costs are borne by the supplier or that the costs are at least shared among the supplier’s customer base. This will not work in the case of a customized solution.
   
   Escrow costs typically consist of a recurring fee to be paid to the escrow agent. In addition, one or both parties may require the escrow agent to verify and test the escrow material (including updates and upgrades). This will also of course come at a cost. If the parties opt for a cloud escrow, there may be additional costs associated with the hosting of a separate mirrored instance.

An escrow mechanism may be a good option to ensure business continuity when relying on on-premise software or a cloud solution of a supplier for business-critical processes or functions. However, an escrow mechanism will only offer the customer the sought-after protection if it is adapted to the specific circumstances of the case. For example, if the solution is frequently updated, it makes sense to agree that the supplier should also place these updates in escrow. It is therefore crucial to reflect and agree on the key principles mentioned above in due time and make sure that these are also reflected in appropriate legal wording.

If you require further information or legal advice in this respect, please contact the authors.