In my work as a consultant I frequently warn clients about the risk of vendor lock-in. This is from bitter experience of being called in to turn around failing projects: if you don’t think about this at the beginning, then it will probably cost you in the long term.

There is no “standard checklist” but here is a good checklist of the main things that I look for:

• Open API: is the API that we will be using (i.e. building a dependency on) open in the sense that it can be freely implemented by competing vendors?
• Standards compliance – does the product conform with relevant industry standards?
• Presence of compatible alternatives – Is there actually another compatible product (either commercial or open source) that we could switch in with minimal changes?
• Open source – is the vendor’s code open source (i.e. under an OSI approved license)?
• Platform independence – is the technology stack portable across different platforms?
• Contractual flexibility – can we terminate or scale back the contract early without significant penalties?
• Independent service provision – are there credible options to buy services from different vendors (i.e. not just the original vendor)
• Capabilities and skills – if we were to part company with the original vendor, do we have the required capabilities and skills to continue working effectively either in-house or with another vendor?
• Record of good behaviour – does the vendor have a good track record that suggests you can trust them not to exploit any lock-in they may obtain?
• Stability of requirements – are our requirements well defined and likely to stay the same? (if so, you can contract for these requirements up front and vendor lock-in doesn’t matter so much…)

If the answer is yes to most or all of these questions, you can be reasonably certain of avoiding vendor lock-in. If not, you should be careful.

These are some guidelines I use when evaluating lock in:

Does the vendor use industry standard formats?

If you end up with tons of files and code that has to speak a foreign language, then switching is exceedingly difficult. If you have standard formats like XML and JSON not so. For instance ASP .Net uses aspx, which is markup that is neither html, nor is it valid XML. This makes it very difficult to convert those files or parse them.

Does the vendor supply sufficient points to integrate with their system?

Can you liberate your data out of the system, and integrate it with your own systems sufficiently via some form of interoperation, like web services? If you want to integrate it with your systems do you need to add more vendor products at a premium?

How hard is it to change out the solution for another one?

A constant sanity check is needed to see how difficult it would be to move away from the vendor. If the vendor’s stuff pervades your entire infrastructure you should be weary.

In short, i would look for reviews and feedback about vendor and the product.

Technically speaking, vendor locking happens when project has tight coupling to the vendor(the third party product).

How to avoid that ? By having alternatives and researching one question about each alternative – How hard is it to change out the solution for another one?

In addition to technical details of product that vendor promoting, it is very important to know the track of success/failure that other customers had with this vendor. It might look hard thing (Goggling, reading reviews, identifying how genuine is the review, etc..) to accomplish. However, there is credible rating system in US called BBB (Better business Bureau).

The records of US based companies in this independent Bureau are very useful and in 95% do reflect the reality. Thus, i will strongly advice to check with them as well.