How to detect and avoid vendor lock-in
Vendor lock-in means making customer dependent on particular vendor. Transition to other (better, cheaper) vendors is much more difficult and customer stays dependent on current vendor. Obviously, this is advantageous for vendor because he will retain revenues from the customer that would otherwise leave.
However this can be only short-term advantage. Low risk of customer leave significantly decreases pressure to introduce innovations. Important is also the ethical dimension. Would you like to build a partnership (normal or strategic one)? Maybe we do not realize that but an example of vendor lock-in are also well known cases of confidential contracts with public administration institutions. However, it is not just government administration and public sector. You can find these practices also in B2B sphere. So let`s not be stupid …
How to recognize risk of vendor lock-in?
1. Think how you will be leaving the solution that you consider to implement before you acquire it.
If you are considering implementation of a new software, ask the vendor, how you will be able to migrate from it to another solution. This question may sound challenging. After all we have not bought the solution yet and we would like to leave it yet? In fact this question is fully legitimate and very fair. If you are reluctant to ask the vendor you probably do not protect your employer interest well. Watch reaction of the vendor. Astonishment, nuisance, downplay do not testify seriousness. If the vendor describes how to migrate, get everything explained well and consider something that is not easy as a big minus. Migration will make you unhappy one day.
2. How to operate the solution without priginal vendor
Ask the vendor whether you will be able to operate the solution yourself or with another company if you want to quit cooperation with the vendor. A provocative question again. However, we do not live twenty years ago and you should have a free choice. Choice that means competition and therefore pressure on price and cost saving for your company. This is a question for various cloud services with regular payments. Annual or monthly payments for solution operation are tempting to conclusion that unlike when acquiring licenses we do not run any risk. We can leave the solution anytime yet.
This is, however, a short-sighted consideration. With monthly/annual payments the vendor is asking to pay more since unlike with licenses, where the payment is secured and de facto advanced, the customer can leave him after couple of months. After couple of years you can then realize that regular payments are actually not that advantageous. Moreover… Would you invest your time, energy and implementation cost to something that you want to leave in one year? Regular monthly payment is good if you want to try a solution. However, if you are serious about implementation, consider everything well and do not believe in hasty conclusions about benefits of regular payments. Do not prefer a priori regular payments to license but compare Total Cost of Ownership (TCO) for 3 and 5 let.
3. How the solution can be extended?
Importance of extensibility probably does not need to be explained. You will need to adapt every solution to your conditions. So what shall we ask the vendor?
Look for various levels of customization which typically differ in ease (low cost for customization) and flexibility (what you can adapt in this way). You do not need a developer for no code development techniques (adding a column, filter etc. just by clicking) and you can manage this in couple of minutes. However, you will not manage more complex things in this way. You will need another layer. Low code development enables development by e.g. scripting. Again you do not need a developer and the development will be fast even if not that fast like just clicking necessary features. However, sometimes even scripting will not do and you will need another extensibility layer – by means of a regular development e.g. in C# .NET or Java.
Does the tool that you are considering cope with this? And which means are used for that? Whenever vendor begins talking about his proprietary distinguishing development environment, remember the vendor lock-in. Instead of proprietary solutions insist on standard technologies. E.g. JavaScript is a very good standard technology that thousands of people manage and that is spreading constantly. You will have no issue to move to another vendor with extensions written in JavaScript if you will not be happy with the current vendor anymore. This will not be possible with a proprietary technology since nobody else will know it…
In conclusion, look for potential vendor lock-in features or the other way around open access and do not believe to quickly made conclusions that some people jump to.