Vendor lock-in is the technical and contractual dependency on a single software vendor that makes switching expensive or impractical. It manifests through proprietary formats, closed APIs, restrictive licensing and monolithic architectures. It's prevented through open architectural choices from the start: recognised standards, portable data and contracts that plan for exit.
There's a precise moment when many companies realise they're stuck. It usually comes when the vendor raises prices significantly, when the platform stops supporting a critical feature, or when you decide to change direction and realise moving your data away is far more complicated than expected. At that point, the real cost of certain technology choices suddenly becomes visible.
Vendor lock-in is exactly this: a condition where the cost of leaving a platform, service or vendor has become so high, in financial, technical or time terms, that change is practically impossible. It's not always the result of a wrong initial choice. Sometimes it's the natural consequence of years of deep integration with a system that worked well. But it's always something that can be prevented, at least in part, if you know what to look for.
The shapes of lock-in: it's not just about contracts
When you think of lock-in you immediately think of multi-year contracts with exit penalties. They exist, sure, but they're the most transparent and negotiable form of the problem. The most insidious forms are technical.
The data lock-in is perhaps the most common. Some platforms make it easy to import data but hard to export it, or export it in proprietary formats that require significant work to be used elsewhere. A CRM keeping your contacts in a non-standard structure, an e-commerce that doesn't allow full export of order history, an ERP producing backups readable only by its own engine: all examples of data dependency that you don't see until you need to leave.
The technological lock-in concerns integrations. The more a system is integrated with others through proprietary APIs, specific webhooks, custom plugins, the higher the migration cost grows. Not because anyone planned it that way, but because every integration is a thread tying the system to the vendor's ecosystem.
Then there's the skills lock-in. If the only person in the company capable of managing a certain system is the vendor itself, or a consultant certified on that specific platform, you're already in a dependency position. It's not just about money: it's about negotiating power. Those who know you can't do without them have little incentive to meet your needs.
The signals you shouldn't ignore
Some situations should ring an alarm bell already during the evaluation of a platform or vendor.
If documentation for data export is vague, incomplete or absent, it's worth asking explicitly how a migration would work. The answer, or the absence of one, says a lot. The same applies to APIs: do they exist? Are they well documented? Do they allow full access to data or only a subset?
Another signal is the closed ecosystem. Platforms that work well only with their native tools, that discourage third-party integrations or make them expensive through proprietary marketplaces, are building a functional dependency around you. It's not necessarily wrong to choose them, but it should be done consciously.
Finally, the pricing model. Tariff structures that grow non-linearly with usage, or that become significantly more expensive as more advanced features are used, are often designed to make change economically painful before it becomes technically difficult.
How to design freer systems
The good news is that there are design principles that structurally reduce single-vendor dependency. They don't eliminate lock-in, but they make it manageable.
The first is to favour open standards. Data formats like JSON, CSV, XML; protocols like REST or GraphQL; databases with standardised drivers: all choices that make data portable and integrations easier to replicate on a different system. When evaluating a platform, always ask: if tomorrow I had to move this data elsewhere, how long would it take?
The second is to separate layers. An architecture where frontend is decoupled from backend, the backend is decoupled from the database, and integrations pass through a well-defined API layer, is intrinsically more portable than a monolith doing everything internally. You don't always need a microservices architecture, but the principle of separation of concerns always applies.
The third is to document integrations. Every connection between systems should be documented, with data flows, formats used, dependencies. Not only to facilitate future migration, but to make the system maintainable over time by anyone, not just by whoever built it.
Finally, negotiate exit clauses before signing. What happens to data if the contract is terminated? In what format are they delivered? Within how long? These are questions that seem out of place during commercial negotiations, but they can make a difference years later.
The specific case of custom software
One of the arguments we often hear in conversations with companies considering custom software is precisely this: "And if your vendor is no longer around, or raises prices, or doesn't want to follow the project anymore?"
It's a legitimate question, and the honest answer is that it depends on how the relationship is structured from the start. Custom software developed on proprietary stack, without documentation, with source code held by the vendor, is potentially more binding than a SaaS platform. On the contrary, software developed on standard open-source technologies, with code owned by the client, adequate documentation and automated tests, is an asset the client can take and entrust to anyone.
At Redergo we always ensure code ownership to the client, using widespread tech stacks and documenting architectural choices. Not because it's a contractual obligation, but because it's the only sensible way to build a long-term relationship. A client who can leave if they want, and chooses to stay, is much more solid than one who has no alternatives.
The cloud is not immune
It's worth spending a few words on the cloud, because it's a context where lock-in is particularly subtle. Big providers like AWS, Google Cloud and Azure offer extremely convenient and well-integrated services. The problem is that the more you use managed services of a single provider, the higher the migration cost to another grows.
A Lambda function on AWS, a Cloud Run on Google, an Azure Function: technically they're all containers, but deployment, monitoring, scaling and integration with other services modes are deeply different. Whoever has built an entire architecture on proprietary services of a single cloud is effectively bound to that provider even without having signed any exclusivity contract.
The answer isn't necessarily to avoid the cloud or give up managed services, but to be aware of where dependency is accumulating and balance it with architectural choices that maintain a minimum level of portability. Containerising applications with Docker, using Kubernetes for orchestration, adopting multi-cloud Infrastructure as Code tools: all practices that increase freedom of movement without giving up cloud benefits.
Freedom of choice as evaluation criterion
The final point, perhaps the most important, is cultural. Lock-in is almost never the result of a single wrong decision, but the accumulation of many small choices made without thinking about exit. Every additional integration, every customisation on a closed platform, every year of contract renewed without renegotiating terms is another brick in the wall.
Evaluating a technology including the potential exit cost in the calculation doesn't mean being pessimistic or distrusting vendors. It means making conscious choices, eyes open on the risks. Companies that succeed have more negotiating power, more strategic flexibility and fewer nasty surprises when the market or their needs change.
And they always do.
