Vendor lock-in is what happens when switching away from a supplier becomes so costly, slow or disruptive that you keep renewing even when you'd rather not. For a Dutch SME it rarely arrives as one decision. It builds up quietly, contract by contract and integration by integration, until the day you actually want to leave and discover there isn't a clean way out.
What Vendor Lock-In Actually Is
Lock-in isn't simply "we use this supplier and are happy with them." It's the gap between what switching *should* cost — your time to evaluate alternatives and migrate — and what it *actually* costs once data formats, contract terms and years of small workarounds are factored in. A business can be perfectly satisfied with a vendor and still be locked in; the two are independent questions. The real test is whether you could leave on reasonable terms if you needed to, not whether you currently want to.
How It Builds Up Without Anyone Deciding It Should
Four things usually combine to create it, and none of them look like a mistake at the time:
Proprietary data formats with no real export. A system that happily imports your data but only exports it in a format nobody else reads, or only as a PDF rather than structured data, is a one-way door. You don't notice it on day one, because you're not trying to leave on day one.
Contract terms that make the timing someone else's choice. Multi-year terms, automatic renewal clauses that need an explicit cancellation inside a narrow window, and early-termination penalties all shift the decision of *when* you can leave away from you. None of these are unusual in IT contracts; the problem is signing them without noticing.
Integrations and workflows built around one vendor's quirks. The longer a system runs, the more other tools, spreadsheets and habits get built around exactly how it behaves — its particular field names, its particular automation rules. Replacing the system then means rebuilding everything that grew around it, not just migrating the data.
Knowledge concentrated in the vendor's platform, not your business. When the only people who understand how your invoicing actually works are the vendor's support staff rather than anyone on your own team, you've outsourced not just the software but the ability to reason about replacing it.
Not All Lock-In Carries the Same Risk
This is where judgement matters more than any rule. Being dependent on Microsoft 365 for email and office documents is a form of lock-in — moving off it is genuinely disruptive — but the risk it carries is low: the vendor is stable, your data exports in widely-supported formats, and a large ecosystem of other providers knows how to migrate away from it if you ever had to. Being dependent on a small, single-product vendor for a business-critical system, in a proprietary format, with no meaningful competitor who can import your data, is a different situation entirely, even if the monthly bill is smaller.
Weigh three things when you're deciding how much a given lock-in actually matters: how replaceable the function is if you had to swap it out next month, how stable and large the vendor is, and what it would genuinely cost — in time and money — to leave if you had to. A dependency that scores badly on all three is worth addressing now, before it gets more entrenched, rather than once it's already causing a problem.
What to Check Before You Sign
Most lock-in gets created at the signing stage, not afterwards, so this is where it's cheapest to avoid:
- Ask exactly how data export works — in what format, whether it costs extra, and how long a full export actually takes. "You can export your data" and "you can export your data in a format our two biggest competitors can both import" are very different guarantees.
- Read the notice period and renewal terms before the term, not after. An auto-renewing contract with a 90-day cancellation window that you only remember on day 89 has already decided the next year for you.
- For anything custom-built, confirm who owns the result. If you're paying for custom software or a custom configuration, the question of whether you own the source code and the configuration — or only a licence to use it through that vendor — decides whether you can take it elsewhere later. Our [custom software development](/services/web-software-development) work is always delivered with the client owning what gets built, precisely so this question doesn't come up later as a surprise.
- Ask whether the system has an API you can actually use, not just one that exists on paper. An API nobody on your side can realistically call is not a mitigant.
- Ask what happens if the vendor is acquired or shuts down. It's an uncomfortable question to ask a salesperson, but a vendor who has already thought about it will have a real answer.
Cloud Specifically Deserves Its Own Plan
Cloud services are where lock-in questions come up most often, because so much of a business's operation ends up running through one provider at once. We've written separately about what to settle with a cloud vendor before you sign and the exit-strategy question most SMEs skip — if you're mid-migration or about to start one, that's worth reading alongside this. Our cloud infrastructure team builds that exit question into the contract and architecture from the start, rather than treating it as something to figure out later if it ever comes up.
If You're Already Locked In
Realistically, most SMEs reading this are not starting from a clean slate — you already have systems, and some of that dependency is already baked in. That's not a reason to panic-migrate everything at once; it's a reason to be deliberate about which dependencies actually need addressing.
Start by separating what's genuinely custom from what's standard configuration of an off-the-shelf product — the second kind is usually far easier to replicate elsewhere than people assume. Test a real export, not a hypothetical one: actually pull your data out in the format the vendor claims is available, and have someone check whether a different system could realistically import it. If the answer is no, that's useful information before you're forced to find out the hard way. And where data genuinely needs to move between systems or vendors in the future, structuring it so it doesn't depend on one platform's internal format is exactly the kind of work our data and databases team does — it's cheaper to build that portability in deliberately than to discover its absence during an actual switch.
Negotiating better terms with your current vendor is also a legitimate outcome here, not a failure to act. A vendor who knows you've priced out the alternative and understand your own exit costs negotiates differently than one who assumes you have no real option but to stay.
FAQ
Is vendor lock-in always a bad sign? No. Depending on a stable, large vendor whose data you can export in a standard format is a mild and often acceptable form of lock-in. The risk comes from combining a small or unstable vendor, a proprietary format, and a business-critical function — not from dependency in general.
Can an SME completely avoid vendor lock-in? Not realistically, and trying to avoid every form of it has its own cost — building everything to be maximally portable usually means more complexity and more maintenance than a small business needs. The practical goal is knowing which dependencies matter and making sure those specific ones have a real way out, not eliminating dependency altogether.
What should a contract include to protect us? At minimum: a clear data-export right in a usable format, a notice period you can actually track, no automatic renewal you'd miss, and — for anything custom-built — explicit ownership of the source code and configuration rather than only a licence to use it through that vendor.
Does building custom software reduce vendor lock-in? It can, but only if you actually own what gets built. Custom software built by a vendor who retains the intellectual property just moves the lock-in from a subscription to a development relationship. Ownership of the code and the right to take it to another developer is what actually reduces the dependency.
How do we know if we're already too locked in to switch? Try an actual, not hypothetical, data export and ask someone independent whether another system could realistically import it. If nobody inside the business can explain how a core process works without referring to the vendor's support team, that's also a sign the dependency has gone further than the contract alone suggests.
Making the Dependency a Choice, Not an Accident
Vendor lock-in isn't something to eliminate on principle — it's something to size up honestly, system by system, so the dependencies you're carrying are ones you chose rather than ones you backed into. Our cloud infrastructure and custom software development teams build the exit question into new work from the start, and our data and databases team can assess how portable your data actually is in systems you're already running — before a forced switch is what tells you the answer.