How to avoid vendor lock-in in the context of software?

CEO captured in a spider web

It is tempting to believe it will not happen to you. Until you read some experiences of users.

Didier Stickens

Vendor lock-in has become a hot topic since companies started to replace their on-premise server capacity by ‘rented’ server capacity in the cloud.  In the context of software, vendor lock-in refers to a situation where the cost of switching to a different software vendor is so high that the customer is essentially stuck with the original vendor.

Reasons to switch vendor

There are three main reasons why you may consider switching to a different software supplier and the situation may become a problem.

  1. The vendor increases his prices to such an extent that they are no longer competitive or the price of his product/service is no longer in line with the value it has to your business (read: a poor ROI).
  2. The quality of the product/service the vendor is providing no longer corresponds the expectations.
  3. Your requirements are changing and the product/service can no longer meet them.

Evaluation of the risks

How much risk the situations above pose to your organization should be evaluated per case. It depends on several factors such as the number of users, the ratio of the cost of the system to other operational costs or the company profit. Also check how business critical the software is. It is important to form an accurate picture of the risks, do not overestimate nor underestimate.

It is tempting to believe it will not happen to you. Below you will find some experiences of users. These quotes are taken from the community page of a popular software vendor (currently active as a SAAS vendor).

Reduce risks

How can you protect yourself from these risks? We first look at the standard software, then we discuss custom software.

Standard software and SAAS solutions

Before you engage with a SAAS-vendor, consider these steps.

  • Make sure it is contractually established that you own the data.
  • Investigate to what extend this software/SAAS supports the export of data. There are vendors that make it very difficult or impossible to export your data. Or they charge based on data volumes to provide your own data. It is clear that this can quickly become very expensive for companies that generate/store a lot of data over time. Some vendors on the other hand make it very easy to extract your data. Of course these are the ones you want to work with.
  • Check if it is possible to use the software/SAAS as it is, and do not have to spend money on consultants to configure or customize it to your needs. This money will be lost when you switch to another package. In addition any customization will make the switch more complicated.
  • Evaluate the likelihood of changing requirements in the future. In that case, it can be beneficial to combine different smaller packages. Those might have a limited functionality, but allow you to select the best solution for each function. In case of changing requirements, you only need to change one of these packages instead of a very big overall migration.
  • Prepare an exit strategy and understand the cost of it.
  • If you happen to have any negotiating power on the contract (most of you won’t), think carefully about pricing conditions. Make sure a renewal decision before end of contract is always sufficient to allow a migration. Put this in the exit strategy as mentioned earlier. From most software/SAAS vendors you will have to accept yearly renewals with potential price increases.
Custom software

In several business cases it can be a real advantage that you can own the source code of the custom software the vendor is developing for you.
Consider these topics to include in the contract:

  • Become the owner of the source code, instead of just getting a license.  
  • Define how you want the source code to be available: on demand (specify how) or on a regular/continuous basis posted in a common repository. These choices depend on how big you estimated the risk and how much you want to be involved.
  • A clause that defines how, how long and at what price support needs to be given in case of transition to a different supplier.
  • Have the application run on a public cloud provider or on your own infrastructure. This makes a future switch to another development partner easier.
  • Make a Service Level Agreement (SLA) including:
    -  The level of expected service and how it will be measured
    -  Pricing
    -  How disputes will be resolved
    -  How follow-up during the contract will be organized (regular status/evaluation meetings)


Depending on the potential impact on the company, it is important to greatly limit the risks of software vendor-lockin. Start with a good evaluation on the impact of the software on your business. Then respect the basic rules as discussed for both custom and standard software.