Is there a set of industry-approved rules to avoid vendor lock-in?

I mean, something one can show to a manager, or other decision maker, that is easy to understand and easily verifiable.

  • Are there any universally accepted set of rules, a checklist or set of conditions that helps detect and prevent vendor lock-in in an objective, measurable way?

  • Have any of you warned a manager about the risk of vendor lock-in during the initial stages of a project?

  • 1
    vendor lock in isn't necessarily a "bad thing"
    – Ryathal
    Oct 24, 2012 at 17:10
  • 2
    This is a surprising good question, that's relevant to a large group of developers. Often you don't know you have this problem until it's too late. Oct 24, 2012 at 17:16
  • Doesn't this question need further clarification as to the particular area of concern that you want to avoid vendor lockin. Otherwise, the answers that anyone can give are common sense (ie. add nothing of value).
    – Dunk
    Oct 24, 2012 at 18:08
  • 4
    @Ryathal Oct: How can a lock-in (restriction of options, future choices) not be bad?
    – Giorgio
    Jun 28, 2013 at 16:09
  • 1
    @Giorgio because support contracts are more important in the business world than ability to change, once a system is working that fact part A can be swapped with part X is irrelevant because no one will do that until there is a gun held to their head.
    – Ryathal
    Jun 28, 2013 at 17:13

3 Answers 3


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.

  • 3
    Another non-technical aspect is: what's the vendors track record with regards to responding to lock-in-related requests. Some vendors are better at it than others. Oct 24, 2012 at 6:56

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.

  • 4
    I'm hesitant to down vote this as it's not "wrong", but your answer doesn't really address the question. Vendor lock-in has nothing to do with the BBB.
    – user53019
    Oct 24, 2012 at 14:28
  • Clarified the missing part of technical detail.
    – Yusubov
    Oct 24, 2012 at 16:13
  • 1
    Good edit - it more directly addresses the question now
    – user53019
    Oct 24, 2012 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.