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.
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).
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.
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.
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:
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).