Cloud computing and the risk of bankruptcy

The risk of discontinuation or bankruptcy

The various forms of cloud computing, and SaaS in particular, have broken through in the past decade as reliable services for the delivery of business-critical software. ERP software and highly specialised software that can have a solid impact on the customer's business operations are used remotely without concern.  

Providers of cloud services, and SaaS providers in particular, are sometimes start-ups or scale-ups with an uncertain future. They are often dependent on investors, and it can take years for them to build an established portfolio of customers. There may therefore be a risk of discontinuation, liquidation or bankruptcy for years. Consequently, it is clear that service discontinuity is a major risk for their clients, all the more so when the business activity of these clients is highly dependent on the software provided. In case of discontinuation, liquidation or bankruptcy, the customer can only hope for a quick takeover and continuation of the activity by a third party. If that fails, the customer will have to find an alternative software solution itself. It will have to query the market, negotiate an agreement, implement an alternative solution and migrate the data from the existing software. Depending on the customer's specific needs and the complexity of the new implementation, this may take months or even years. In the meantime, however, the customer must find a way to continue using the existing software for the time being, during a sufficiently long transition period. 

When a SaaS provider ceases its activity and proceeds to liquidation, it may itself opt to discontinue services in the short or long term. However, sometimes the decision to discontinue is also made by a third party. This is because a SaaS provider usually relies on a hosting provider to host the software offered. This host may be one of the big players, such as AWS, Azure or Google, but may as well be a smaller data centre operator. Contracts with such hosting providers include, as a standard clause, that the host can terminate the agreement in case of bankruptcy, liquidation, cessation of activity, and even earlier, in case of symptoms of insolvency. Thus, in case of payment difficulties, the host can suspend or discontinue hosting, which would automatically terminate the SaaS service. In the event of bankruptcy of a SaaS provider, the receiver appointed to wind up the bankruptcy has the power to decide on the continued performance of contracts with the clientele and with the host. Indeed, when it is necessary for the winding-up of the bankruptcy, the receiver can decide to discontinue a contract or simply not to continue its execution (Article XX.139 Code of Economic Law). He can do so, for example, in the interest of creditors when the service is loss-making and there is no prospect of an early takeover. The customers cannot then claim continuation of their contract. They may have a claim for compensation, but it will usually yield little. 

In any case, it is absolutely important for customers who purchase business-critical software to be able to guarantee continuity of use of the software, at least during a transition period long enough to organise an orderly transition to an alternative system and limit the damage to business operations. Furthermore, to the extent possible, it is also appropriate not to place the fate of the service in the hands of a receiver. Indeed, a receiver may intend to sell the software, usually the sole asset of the bankrupt, to an acquirer. Also then, the fate of existing customers is uncertain. Moreover, due to the receiver's lack of technical knowledge, considerable time may be lost before he believes he has understood the situation sufficiently to take the appropriate decisions. In the meantime, however, customers remain in a precarious situation. A SaaS-dependent customer must therefore foresee the potential risks of a discontinuation or bankruptcy, especially when the SaaS provider is economically vulnerable. 

Escrow of source code is poorly suited

In the past, software was mainly installed as on-premise software on customer computers or servers. This still happens, but more and more software is offered in the cloud. In case of failure of the licensor, on-premise software is physically present and accessible to the customer. If the customer can ensure that a third-party service provider or possibly its own staff can continue to provide maintenance to the software, such as performing necessary modifications and correcting bugs, the software can continue to run on the customer's system for a certain period of time, pending a transition to a new system. To perform such maintenance, however, the customer must have the source code of the software. The source code is the readable and editable form of the computer programme. 

In practice, the source code escrow system was devised to provide a temporary solution. This system involves a tripartite custody agreement between the customer, the licensor and a third-party custodian, the escrow agent. The escrow agent keeps a version of the source code of the software, and will release it to the customer when the "release" conditions mentioned in the contract occur. Bankruptcy or cessation of business are the main release conditions. Importantly, the obligation to release the source code is the escrow agent's own obligation, which cannot be prevented by the receiver. Under the source code escrow system, the customer is given the right to modify and maintain the software itself or with the help of third parties (possibly former staff of the bankrupt) for a period sufficient to look for alternative software. The fact that the customer has the source code in theory gives a certain autonomy to the customer, which can mitigate the consequences of bankruptcy (to the extent that it is actually possible in practice to modify the software with suitable persons).  

The special issues of SaaS and cloud computing

In the context of cloud computing, the consequences of discontinuation and bankruptcy are even more drastic than for on-premise applications. This is because the software is offered online and hosted either in the cloud or in a private data centre. Moreover, if the hosting environment is a multi-tenant environment, the resources are also shared with other customers. This means that the customer does not have the physical software, and therefore cannot simply continue to use it, let alone modify it. 

Moreover, the software runs in a dedicated SaaS or PaaS environment, which is very different from an on-premise environment. Even if the customer were to obtain the source code of the relevant programmes through an escrow system, implementing the software is an almost impossible task. And even if the latter were to succeed, much time has often passed in which the company could not use the software. If business-critical software is involved, this can result in irreparable business damage. So for the various forms of cloud computing (SaaS, PaaS and managed services), source code escrow does not offer a solution. 

Although most companies are generally well aware of the importance of data recovery (another major risk in case of service discontinuation), in Belgium both customers and providers of cloud solutions as well as local escrow agents still seem insufficiently aware of the risks of a complete discontinuity of the use of the software itself. In contrast, abroad, more attention is already being paid to this risk and a number of more or less creative solutions are already being offered. 

In search of solutions

Given the difficulties of a migration and on-premise deployment of the relevant applications and the environment in which they are embedded, the solution must be found in either a continuation of the existing configuration at the hosting provider, or a quick switch to a backup environment hosted elsewhere, mirroring the live hosting environment.

1. A backup environment at a third party replicating the live environment
   In our practice, we have noticed that some SaaS providers manage to set up a backup system at an acceptable price, hosted by a third party. Moreover, this backup environment also contains the relevant source code. In this solution, the live environment is continuously replicated to the backup environment. A tripartite agreement is then concluded with the third party. In case of discontinuation or bankruptcy of the SaaS provider, this third party will release the backup environment to the customer as its own obligation. This too cannot be prevented by a receiver. The backup environment thus acts as a protection, so to speak, in the event of discontinuation or bankruptcy and can also potentially serve as a failover system in case a disaster would affect the live environment. This is thus a first possible solution, which however in practice sometimes proves too expensive for a number of customers. 
2. Escrowing credentials and data that give access to the live environment
   Alternatively, some escrow agents have worked out a system whereby the SaaS provider places the credentials and other data needed to access the hosting environment, along with the technical documentation of the environment, in escrow. Based on the escrow agreement, this information is then released by the escrow agent to the customer in case of discontinuation. The customer will then have access to the live environment and will be able to continue working with the software temporarily if it has the technical resources to maintain the software during a transition period. In this case, however, the customer will have to continue bearing the hosting costs. This second solution may be suitable for single-tenant situations, but is more difficult to apply in a multi-tenant environment where multiple customers, often competitors of each other, depend on the applications and their data stored in that environment. 
3. Obligation to continue paying the hosting provider
   Other solutions are more focused on upholding payment of the hosting provider during a certain transition period. For example, a number of SaaS providers set up a trust, not-for-profit or similar legal entity in addition to their operating company, into which funds are regularly deposited that are required to be used in the event of the operating company's bankruptcy. This legal entity will then continue to pay at least the hosting provider's costs during a transition period, during which affected customers can seek an alternative solution. 

Conclusion

No solution will be perfect in practice, and in any case, the question remains whether one can practically use the software if one cannot recover staff from the bankrupt company. This also raises the question of how long such transitional situations should last, especially if the customer has to look for an alternative solution that can only be implemented after a considerable period of time. In any case, it is important that buyers of business-critical software sufficiently anticipate these risks and work out a solution that can minimise the harmful consequences. 

Important questions when choosing business-critical software are therefore: 

1. Will the software be delivered on-premise or in the cloud? 
2. If it is an on-premise software: 
   • Was provision made for escrow of the source code in case the service provider goes bankrupt? 
   • Can you use your own staff or third parties to maintain the software upon release of the source code?  
3. If it is cloud software: 
   • Is the service provider sufficiently financially resilient? 
   • Is there a mechanism provided so that the company can still have (temporary) access to the live environment if the service provider goes bankrupt? 

In any case, it is important to sufficiently anticipate the risk of failure of the service provider and build in the necessary fall-back solutions. This usually requires a well-negotiated contract with the service provider that makes sense both legally and IT-wise.

Should you still have questions about cloud computing and the risk of bankruptcy: schedule a short interview with Stefan Van Camp (reserved for organisations).