Most people who ask us about vendor lock-in have already been through it once. They own a system that works, they own the code by contract, and they still can’t change suppliers without starting again. That gap between owning something and being able to use it is what lock-in actually is, and it catches careful buyers as often as careless ones.
The reassuring part is that it’s structural rather than legal. Nobody wrote a clause to trap you. The trap is a set of conditions that accumulate during construction, and every one of them can be prevented by decisions made before the first commit.
This guide covers what lock-in looks like from the inside, the terms to insist on before you sign, and what a handover has to include to count as one.
What Lock-In Actually Looks Like
It rarely announces itself. A system is delivered, it works, and everyone is satisfied. Then a requirement changes eighteen months later and the real condition of the asset becomes visible all at once.
Four things are almost always present, and they are worth naming individually because each has its own remedy:
- No Tests, So Nothing Can Change Safely. Without automated tests, nobody can state what a change will break. The system isn’t fragile in a technical sense, it’s simply unknowable, and a rational developer refuses to touch it. We’ve seen platforms frozen for years in perfect working order for exactly this reason. The business didn’t stop because the software failed. It stopped because nobody was willing to modify it.
- Undocumented Architecture. Not missing comments. Missing rationale. Why this database, why this queue, why the integration retries three times and then gives up. The original author held it all in their head, was never asked to write it down, and took it with them. An incoming developer has to reverse engineer intent from behavior, which is slow, expensive, and often wrong.
- A Deploy That Lives on One Laptop. A release process that depends on one machine, one set of local credentials, or one person’s shell history. It works right up until that person is unavailable, and then it doesn’t work at all. If your team cannot deploy today, without calling anyone, you’re locked in regardless of what the contract says.
- Infrastructure Nobody Can Reproduce. Servers, buckets, queues, and DNS records configured by hand in a console over three years. Nothing records how they got that way. This is a constraint on scaling and on disaster recovery simultaneously, and it’s the one that turns a supplier change into a rebuild.
You’ll notice none of these are about who holds the copyright. That’s why “we own our code” is not the protection people expect it to be.
The Terms to Insist On Before You Sign
Every one of the conditions above is cheap to prevent and expensive to reverse. These are the terms to settle during negotiation, while you still have leverage:
- The Repository Lives Under Your Organization. Not a copy delivered at the end. Your GitHub or GitLab organization, your account, from the first commit. This is the single most effective clause available to you, because it makes progress observable throughout and means the work is already in your possession if the relationship ends abruptly. It’s how we work as standard: source is committed to the client repository, under the client organization, from commit one.
- Cloud and Third-Party Accounts in Your Name. AWS, Cloudflare, the domain registrar, the error tracker, the payment processor. Your supplier gets access to your accounts, not the other way round. Accounts held by an agency are the most common form of practical hostage-taking, and it’s usually accidental rather than malicious, which doesn’t help you when you need the DNS changed on a Friday.
- Tests and Documentation Named as Deliverables. If they aren’t line items, they’re the first thing cut when the schedule tightens. Ask for an automated test suite enforced by continuous integration, architecture documentation covering decisions and rationale, and runbooks for deployment, rollback, and incident response. Those are three of the seven deliverables listed on our software development practice page, and they’re the three that determine whether you can leave.
- Infrastructure as Code, Reproducible from an Empty Account. The test is literal: could a new engineer stand the whole environment up from source in a fresh cloud account? If yes, your infrastructure is portable. If no, it exists in exactly one place and can’t be moved.
- No Proprietary Framework You Can’t License. Some firms build on internal tooling they don’t hand over. It’s sometimes reasonable and it’s always worth knowing about in advance. Ask directly what’s theirs, what’s yours, and what you’d need a license for after the engagement ends.
- A Defined Exit. What happens on termination, what gets transferred, in what format, and within how long. Agreeing this while everyone is optimistic is considerably easier than agreeing it later.
What a Real Handover Looks Like
Handover is usually scheduled as a final phase, which means it sits at the end of a schedule, and the end of a schedule absorbs every preceding delay. It gets compressed into a slide deck and a call. That isn’t a handover, it’s a description of one.
A handover that establishes anything has a pass condition, and the condition is behavioral: your developer, not theirs, performs a deployment to production unassisted. We treat successful independent deployment as the completion criterion for the transfer stage, because everything else is a claim about the future made by the party with an interest in the answer.
Around that session, expect:
- Architecture documentation covering decisions and rationale, so the next developer inherits reasoning rather than only behavior.
- Runbooks for deployment, rollback, and incident response, written to be followed at three in the morning by someone who didn’t build the system.
- API documentation generated from the implementing source, which is the only version that stays true.
- Credentials rotated into your own secrets management, with the old ones revoked rather than merely unused.
- A recorded handover session and a named technical contact, so the knowledge survives the person who attended.
Support after that point should be something you choose, not something you need. Ours is arranged monthly and structured so it can be discontinued without operational risk, and plenty of engagements end it once the internal team has found its footing. That’s the intended outcome. A retainer that exists because the client has no alternative isn’t a support arrangement, it’s the lock-in you were trying to avoid.
If You’re Already Stuck
Most of the systems we’re asked to look at are in this position, and the first thing worth saying is that a rewrite is usually the wrong answer. A system that works and a system that can be changed safely are two different problems, and only one of them requires rebuilding.
The recovery sequence is fairly consistent. An audit establishes what the system does and ranks the risks. Characterization tests capture current behavior so that changes become measurable rather than terrifying. Infrastructure gets defined in code so it can be reproduced. Credentials come out of the spreadsheet. Then, and only then, does anyone start changing features.
Our audit and remediation of an inherited operations platform walks through this on a real engagement, including the recommendation not to rewrite and what the eleven weeks of remediation actually consisted of. If you’re weighing that decision, our note on what custom software development costs covers how remediation and replacement tend to compare.
Ownership Is Built, Not Signed
The contract matters, and it should say what we’ve described above. But the thing that determines whether you’re free to walk away is how the system was constructed: whether it has tests, whether the reasoning was written down, whether anyone other than its author can deploy it.
That’s decided in week one, not at handover. It’s worth asking about on the first call, and worth being skeptical of any answer that sounds like a promise rather than a practice. If you’d like ours explained in detail, our software practice sets it out, and you’re welcome to get in touch.