For the past several years, the so-called cloud has been gaining popularity. This refers to systems that are set up and maintained on the servers of an external provider, who takes care not only of servicing but also of the maintenance and development of the software. The popularity of this model stemmed not only from the wide range of suppliers offering such solutions, who, by providing a comprehensive package, could more easily optimize their margins and manage product development. The key was how well it aligned with customer needs.
'Cloud' software offered the tempting convenience of offloading responsibility for the system's infrastructure from one's own IT structures. Therefore, both purchasing departments and those involved in business process execution within companies repeatedly chanted 'SaaS' in its various forms, like a mantra. This was true in both the private sector and public sector organizations, where the move to the cloud offered the same benefits but faced significantly more legal restrictions.
Despite its undeniable advantages, one rather crucial issue for business continuity and security remained somewhat in the shadows. If we adopt a solution and become dependent on its benefits, we need to know how to operate when someone 'pulls the plug.' The answer to this question, for specialists in new technology law, has a name – exit strategy.
Why do we need an exit strategy?
The way software is sold in the SaaS model is quite standardized. The seller has a ready-made solution that they offer to the client, most often as a so-called 'box' or 'boxed' solution. This could be a general ERP system or software to handle a specific process, but it usually has a predefined scope of functionality and customization options. The more customization and data exchange with other systems in the company (or databases), the longer the implementation takes because the scope of integration needs to be planned. The standard terms and conditions and agreements proposed by the provider define all the basic elements of using the system, including the scope of system availability.
The question may naturally arise: if we are buying an 'off-the-shelf' solution, why do we need to plan for decommissioning such software? After all, if we turned it on, we can simply turn it off, i.e., deactivate access and turn on another system. It sounds deceptively simple, but in practice, it isn't. This is because every system operates on data that we enter into it, store within it, and further process. With our own infrastructure, we have control over where and for how long this data resides. By operating in a system managed by third parties, we pay for the convenience of use with a loss of control. Therefore, an exit strategy, which should be understood as a description of the actions to be taken by both the system provider and the company using the SaaS, is a guarantee of a smooth migration.
Where does creating an exit strategy begin?
Before deciding to purchase SaaS, companies should ask themselves several questions about what using such software will look like in their daily operations and how deeply it will become embedded in their business. They need to allow for answers to questions such as:
- is data uploaded to the system or retrieved in real-time and saved to a database on a local server,
- what happens to the data entered into the system when the subscription ends,
- who oversees the configuration of the system's API for other company solutions,
- does the provider perform backups of the SaaS software, and what is their scope and retention period,
- what are the ways to terminate the agreement for access to the system, and how much time will there be for migration to another solution,
- do we have another alternative solution, or will we need to start the purchasing procedure if the subscription ends.
It seems simple, right? However, formulating the appropriate clauses in agreements regarding the purchase of systems is difficult. On the one hand, this is because they need to be properly incorporated into the already prepared content in the provider's standard agreement. On the other hand, the provider may resist disclosing detailed information about the infrastructure configuration for security reasons. Especially since, in the SaaS model, responsibility for the code should lie entirely with the provider (if you are interested in this topic, I invite you to read the article on responsibility for the code).
Therefore, the agreement should include clauses absolutely necessary to ensure proper cooperation between the parties upon termination of the collaboration. Minimum content, maximum effect – such an outcome is possible if the purchasing team has relevant experience in such matters.
What if we cannot negotiate the terms of the SaaS agreement?
Depending on the form of business operation, it is ultimately the management or the owner of the company who decides whether to accept the risk of adopting a particular technology. This is true both for companies that operate based on management systems built according to ISO standards (where the management's responsibility for accepting risks and opportunities is literally written in the system documentation) and for the rest of the market that operates only within the framework of the Commercial Companies Code and in accordance with the principles of civil law.
This means that when choosing a specific product, the first step is to check whether the issues of terminating the collaboration are detailed in the documents presented by the seller. If not, the decision to enter into cooperation must be preceded by determining whether the provider will engage in discussions and make changes to their standard documents. As we know, BIG TECH companies do not negotiate with small clients, if with anyone at all.
Should we not implement a system for which the provider has not established an exit strategy with us? Of course not. But all the work rests on the buyer, who must independently plan their actions related to the termination of cooperation and analyze the associated risks for their business.
