What is Vendor Lock-in and How to Avoid It?

Where Dependency Really Arises

Not primarily in the source code. The more common causes are:

• No access to the repository. The code is with the service provider, you have never seen it.
• No documentation of the environment. The code alone is useless if no one knows how it is delivered and operated.
• Access credentials only with the service provider. Domain, server, certificates, service accounts.
• No data export. Your data is in a database that you cannot access.
• Only one person knows the system – on both sides.

Five Effective Measures

1. Repository Access from Day One

Not at the end of the project. An account with read access costs nothing and changes everything.

2. Access Credentials in Your Possession

Domain, hosting account, and certificates should be in your company's name, even if the service provider manages them.

3. Operational Documentation as Deliverable

How is it delivered, what dependencies exist, what does a backup look like, how is a restore done? This should be in the contract, not left to hope.

4. Regular Data Export

An export format that is readable without the application. Test it once a year.

5. Common Technology

An application in widely used technologies can be taken over by any qualified service provider. An exotic stack makes you dependent on the few people who master it.

The Honest Assessment

Some dependency cannot be avoided – whoever built a system knows it best. The goal is not independence at any cost, but to ensure that a switch remains possible. This possibility alone changes the relationship.