Vendor lock-in is rarely a decision anyone makes. It is a series of small, reasonable-looking conveniences that add up until leaving costs more than staying, even when staying is clearly the worse option.
It is also not automatically bad. Every meaningful tool creates some switching cost, and chasing zero lock-in produces software that is portable, generic, and worse at the job. The goal is not avoiding it. The goal is knowing exactly how much you are accepting and what it would cost to undo.
The four kinds of lock-in
Data lock-in. Your information lives in their system in their format, and getting it out produces a CSV that loses half the structure. This is the most common and most damaging kind, because your data is the part that is genuinely irreplaceable.
Platform lock-in. Your application is built on proprietary services that have no equivalent elsewhere. Moving means rewriting, not migrating.
Knowledge lock-in. Only the vendor understands how your system works. There is no documentation, no handover material, and nobody on your side who could brief a replacement. This one is invisible until the day it matters.
Contractual lock-in. Multi-year terms, auto-renewals with narrow cancellation windows, and termination fees. The most honest kind, because at least it is written down.
The questions to ask before signing
Ask these in writing, and treat evasive answers as answers.
Can I export all of my data, in a usable format, without asking you? The word doing the work is “usable.” A PDF of your customer list is technically an export and practically useless. What you want is structured data that another system could actually import.
Who owns the source code, and where does it live? If the answer is that it lives in the vendor’s repository under the vendor’s account, you own a service, not an asset. That may be fine, but it should be a decision rather than a discovery.
Whose accounts are the infrastructure accounts? Hosting, domain, database, email, payment processor. If those are in the vendor’s name, they hold the keys to your business operations. Domains registered by an agency and never transferred are a classic and painful version of this.
What does offboarding actually look like? Not whether it is possible. What are the steps, how long does it take, what does it cost, and has it been done before? A vendor with a documented offboarding process is telling you something meaningful about how they operate.
Reading the contract for the parts that bite
Three clauses matter more than the rest. Auto-renewal terms, especially the notice window, because a thirty-day cancellation window on an annual contract is a trap dressed as a formality. Data retention and deletion after termination, because you need to know how long they hold your data and whether you can get a final export. And any clause tying support quality or data access to being a current customer, which turns a routine departure into a hostage negotiation.
When accepting lock-in is the right call
Sometimes it is. A managed platform that saves you an engineer’s salary is worth real switching cost. A specialized tool with no comparable alternative is worth depending on if it does the job well. A vendor whose proprietary layer genuinely outperforms the portable option is a reasonable bet.
The distinction is between lock-in you accepted in exchange for something and lock-in you drifted into by default. The first is a trade. The second is just exposure. Our build versus buy framework works through where that line usually falls for small businesses.
Reducing exposure without rebuilding anything
You do not need to redesign your stack to be meaningfully less locked in. Four things cover most of the risk.
Own the accounts. Domain, hosting, and infrastructure should be registered to your business with your billing details, with the vendor added as a user. This single change removes the worst-case scenario in most disputes.
Export your data on a schedule. Quarterly is plenty. It gives you a fallback and, more usefully, tells you early whether the export is actually any good.
Insist on a plain-language architecture document. What runs where, what depends on what, where the credentials live. One page is enough. This is the antidote to knowledge lock-in and takes a competent vendor an hour to produce.
Keep the source code in a repository you control. Vendors push to it. You own it. This is standard practice and any pushback is informative.
The signal worth trusting
A vendor confident in their work does not need to trap you. When we hand off a project, the client owns the code, the accounts, and the documentation, and could hire someone else tomorrow. That is not generosity. It is the only arrangement where the client staying means the work is good rather than that leaving is expensive.
If you are not sure what you signed up for on an existing arrangement, the fastest way to find out is to request a full data export and an architecture document. What comes back, and how quickly, tells you most of what you need to know. We are happy to look at what you get and tell you where you actually stand.
Want to know how locked in you already are?
Request a full data export and an architecture document from your current vendor. Send us what comes back and we’ll tell you exactly where you stand.
Get a Free Consultation