Most businesses only discover they have a vendor lock-in problem when they try to leave.
The project to switch platforms drags on for nine months longer than planned. The data export comes out in a format nobody can easily work with. The new vendor won't support the API your custom integrations were built on. By the time the full cost of switching becomes clear, the organisation is usually so deep in the migration that it has no real choice but to keep going — at whatever cost.
Vendor lock-in is not a new problem, but it is getting more common as business software becomes more interconnected. The more systems a supplier touches — your data, your workflows, your staff's daily habits, your customer-facing operations — the more leverage they hold if you ever want to leave. Understanding where that leverage comes from is the first step to negotiating better terms.
What is vendor lock-in, exactly?
Vendor lock-in is a situation where the cost of switching from one supplier's software to another is high enough to make switching practically difficult, even when the current supplier is underperforming or overcharging.
It is worth being precise here because the term gets used loosely. Lock-in is not the same as having a long contract. A two-year contract with easy data export and standard integrations is not lock-in — it is a fixed term. True lock-in exists when the switching cost, not the contract term, is what keeps you in place. The contract term ends; the switching cost doesn't.
The distinction matters because it changes what you should be negotiating. If the real risk is switching cost, then the most important contractual protections are about data portability, API access, and integration standards — not just break clauses.
What are the main types of vendor lock-in?
Lock-in takes several forms, and a single supplier can have more than one of them at once.
Data lock-in
Data lock-in is the most common and most damaging form. It happens when your data lives in a proprietary format or database structure that can't be easily exported in a way another system can use.
Many SaaS platforms offer data exports that are technically complete but practically useless — a CSV dump of fifty flat tables that represent what was actually a complex relational database, with no schema documentation and no way to understand how the tables relate to each other. The data is there, but making it work in a new system requires months of data engineering.
Before committing to any platform where your data will accumulate over time, ask specifically: what does an export look like, and can we import it into a competitor's product? If the vendor cannot answer this clearly, that is a warning sign.
Technical lock-in
Technical lock-in occurs when your integrations, customisations, or internal tooling are built on proprietary interfaces that only work with that vendor's product. This often happens gradually. A team builds a workflow on top of a vendor's API, then extends it, then builds a second workflow that depends on the first — and suddenly a large part of your internal operations depends on that API continuing to work exactly as it does today.
This is closely related to the problem of API stability. A vendor can technically keep their API available while changing it in ways that break your integrations — a problem distinct from outages that is worth understanding separately.
Contractual lock-in
Some lock-in is deliberate and structural: long minimum terms, automatic renewal clauses with short cancellation windows, penalties for early exit, and price escalation tied to inflation indices that compound faster than your usage growth. None of these are inherently unreasonable, but they are worth understanding clearly before you sign.
Auto-renewal clauses in particular catch businesses out. A contract that auto-renews on sixty days' notice, combined with a team that doesn't track renewal dates, means you often end up committed to another year before anyone noticed the window had closed.
Process lock-in
Process lock-in is the form that businesses least expect and find hardest to escape. It happens when your team's workflows, training, and institutional knowledge are built around a specific product's way of doing things.
This is not a technology problem — it is a human problem. Staff who have been doing their jobs in one tool for three years have built up habits, shortcuts, and mental models that are specific to that product. Switching tools means retraining, dealing with productivity loss during the transition, and sometimes losing staff who prefer to leave rather than adapt. The more deeply embedded a tool is in daily operations, the higher this cost.
Pricing lock-in
Some suppliers set low prices in the early years to generate adoption, then raise prices once switching costs are established. This is especially common with platforms that have strong technical and process lock-in — the supplier knows you can't leave easily, and adjusts the price accordingly.
This is not a reason to avoid platforms that start affordable. But it is a reason to model what your costs look like at two times and five times your current usage before you commit, and to negotiate price caps in your contract if the platform is core infrastructure.
How do you evaluate lock-in risk before you commit?
There are four questions worth asking any software vendor before you sign a significant contract.
What does a full data export look like? Ask them to walk you through it. If they offer a live demo environment, request a sample export. Look at whether it's in an open, widely supported format, and whether it includes everything — attachments, metadata, relationship structure, historical records.
What happens to our integrations if your API changes? A mature vendor will have a versioning policy and a deprecation timeline. If they don't, or if they can't tell you what notice period you'd receive before breaking changes go live, your integrations are more fragile than they might appear.
What is the actual notice period to cancel, and when does it apply relative to the renewal date? Have someone read the contract language carefully, not just the sales summary. The gap between the renewal date and the cancellation deadline is where businesses get caught.
Who else has left your platform and what did the migration look like? Most vendors won't answer this directly. But the existence (or absence) of migration guides, community posts, or third-party migration tooling tells you a lot about how frequently customers successfully exit and how much institutional support exists for the process.
What can you do if you're already locked in?
If you are already in a position of high lock-in with a supplier, you have a few options — none of them fast.
Start accumulating leverage. If your contract is up for renewal, this is when you have the most negotiating power. Use it. Push for longer price stability, better data export terms, and more favourable cancellation conditions. Vendors who want to retain a customer are often more flexible than their standard terms suggest.
Build an exit plan even if you don't intend to use it. Documenting the steps required to migrate — what data would need to move, which integrations would need to be rebuilt, which workflows would need to be redesigned — gives you a realistic picture of switching cost. This information is valuable in two ways: it helps you negotiate (you can quantify what you're accepting by staying), and it prevents the cost from being an unpleasant surprise if you do eventually need to leave.
Reduce your surface area. If the lock-in is partly technical, audit which integrations actually need to be built on the vendor's proprietary API versus an open standard. In many cases, businesses have built more proprietary integrations than necessary because it was easier at the time, not because it was required.
When does building custom software change the equation?
Custom software does not eliminate lock-in — it shifts who holds the leverage. If you build a bespoke system, the lock-in risk moves from the software vendor to your development partner and to the technology choices made during the build. A system built on widely adopted, open-source technology is much easier to hand off to another team than one built on a proprietary framework that only one development shop knows how to maintain.
The advantage of custom software is that you control the data model, the export format, and the API structure. You can design these to be portable from the start, rather than negotiating with a vendor to give you access to your own data. That control is worth something — but only if portability is designed in from the beginning, not assumed.
If you are making a significant software decision and lock-in risk is a factor — either because you are evaluating a new platform or because you are already feeling constrained by a current one — this is the kind of question a short IT consulting or technical advisory engagement can help you think through. The cost of getting a clearer picture before you commit is almost always lower than the cost of untangling the wrong decision later.
You can read more about how I work with businesses on software decisions, or get in touch if you have a specific situation you want to think through.