
AI vendor lock-in, for a small business, comes down to one question: if this arrangement ends, what am I still holding, and can I open it without the person who built it? The short answer is that you keep whatever sits in files you can open, and you lose whatever was rented. No client has ever asked me to hand a system over, so I cannot show you what leaving me looks like. What I can do is run the exit on myself. This morning I audited all 57 systems I have built as if a client were walking out tomorrow. The files passed: 4,168 of 4,814 are plain text, and all 33 databases are one open format. My own paperwork failed. Three contract templates say the client owns the work, and not one of them says how the client gets it. This is the audit I would want to see before bringing anyone on for AI and data work, me included.
Most advice on AI vendor lock-in is written for companies with a legal team
Nearly every guide to AI vendor lock-in assumes a procurement office and a budget for migration. The search results are definitions, contract clauses to negotiate and readiness scorecards, and the best data in them describes large companies. A survey Zapier published in April 2026 asked 542 U.S. executives and decision-makers at organizations that pay for AI vendors. Among them, 89% said they could switch vendors within four weeks. Two thirds had already tried, and 58% of those said the move either failed outright or took significantly more effort than expected.
Europe has written the exit into law. Under the EU Data Act, which has applied since September 12, 2025, cloud providers lose the right to charge a customer for switching away, data transfer fees included, from January 12, 2027. The EU rule does not reach a contract between two Ohio businesses, where the right to leave with your work exists only if somebody wrote it into the agreement.
What a small business needs is four answers, not a scorecard, and the rest of this post gives mine.
- Is my data in a format I can open without you?
- Can I keep running what you built, and do I have the right to?
- Whose name is on the accounts it depends on?
- Is there a written handover, and how fast do I get it?
Nearly all of what I have built opens in a text editor
Of the 4,814 files in my 57 systems, 4,168 are plain text, which is 86.6%. Plain text means a file made only of readable characters. I measured the 86.6% from the contents and not the file names, with a script that read the first 8,192 bytes of every file. The 4,814 leaves out downloaded libraries, logs and the databases, which get their own count below. The 57 systems run from websites to scheduled agents to the tools that run my own office, and they add up to about 367,000 lines of code and markup.
The other 646 files are 606 images, 12 PDFs, 12 font files, 9 reference data files, 6 Office documents and 1 video. Not one file in the pile needs a program that only I have. Plain text matters for a reason that has nothing to do with programmers. A text file opens on any computer with no special software, and the next person you hire can read it on their first day.
Every database is a single file in a format the Library of Congress recommends
All 33 of my live databases are SQLite files, confirmed by reading the 16-byte signature at the top of each one. SQLite is a database that lives in one ordinary file with no server behind it. Twenty of the 57 systems hold at least one, the 33 files total about 1.4 gigabytes, and another 1,080 backup copies are the same format.
The SQLite format is what makes those 33 databases portable. The Library of Congress lists SQLite among its preferred formats for preserving datasets, alongside plain CSV. SQLite's developers intend to support it through the year 2050 and promise to keep the file format backwards compatible. A client who leaves with a SQLite file can open it with free software, and so can whoever they hire next.
One system does not pass. An unfinished app in the pile was written against a hosted database service, and its own sign-in screen reports that the connection keys are missing. The unfinished app is the one thing in the audit I could not hand over as a folder, because part of it would live in an account, and an account is not a file.
The model is the one part nobody owns, and it gets replaced on a schedule
You never own the model, and neither do I. Twenty-one of my 57 systems call a hosted language model, meaning an AI model that runs on the vendor's computers and is paid for by the request. Each of those 21 rents its most capable part. Anthropic, the vendor most of them call, publishes its retirement schedule: at least 60 days' notice, and after that, in its words, "Requests to retired models will fail." Nine models were switched off on that schedule between October 28, 2025 and August 5, 2026. A tenth is set for November 30, 2026.

A retirement is a planning fact, not an emergency, as long as the model's name is the only thing that has to change. In my code a model is named in 31 files across 19 systems, and in 13 of those systems the name sits in exactly one file. I also know what a swap costs, because I did one last night. On October 8, 2026 I checked every agent that calls a model against the newest ones and moved the ones that were behind. The move came to four commits: 181 changed lines across 14 files in four systems. One system accounted for 122 of the 181 lines, because the newer model refuses a kind of request the older one accepted, and the code around the call had to change with it.

The audit also found what happens to systems nobody is tending. Three dormant ones still name a model that is gone or going: one retired on February 19, 2026, one that Google shut down on June 1, 2026, and one scheduled for removal in February 2027. Every system that is running names a model its vendor still serves. The difference between the dormant systems and the running ones is upkeep.
What you do own is the output. On business terms, Anthropic's commercial contract says the customer "owns its Outputs" and that Anthropic may not train its models on what the customer sends. The question most owners ask first is already settled in writing. The open question is whether everything around the model belongs to you.
Newer AI makes rewriting cheaper, and it cannot rewrite what you were never given
The newest models have not ended lock-in, but they have changed what it costs. The case that they ended it is in print: an Entrepreneur piece from August 31, 2026 argues that AI has cut the effort of migrating off an old system so far that lock-in is quietly going away. Part of that argument is right, and the model swap I made on October 8 is an example. Rewriting is cheap now. There is also real movement toward neutral ground. On December 9, 2025 the protocol AI apps use to reach outside tools was donated to a foundation under the Linux Foundation, co-founded by Anthropic, Block and OpenAI. The same foundation took in AGENTS.md, the plain-text instruction file my own systems and public kits already use.
A rewrite needs something to read, though. On June 3, 2026 OpenAI announced the retirement of its Agent Builder product and of the reusable prompts customers had stored in its dashboard, both shutting down November 30, 2026. A prompt is the written instruction a model follows. OpenAI's migration advice for the stored prompts opens with one line: "move reusable prompt content into your application code." Application code is where the prompts would have been all along if the customer had held them. The same page carries 36 dated retirement notices, 14 of them from this year.
I have been on the leaving side of this once. In August 2026 I retired an automation platform I had run my own workflows on. The archive came with me, 18 megabytes of workflow history, and nothing else I run can execute it. Every workflow was rebuilt as a plain script. The rebuild was possible because I knew what each workflow did. A business that had only ever seen the dashboard would have been starting over.
A copy of the folders leaves out the accounts, the settings and the instructions
The folders are the easy part of a handover, and most of what makes a system run is not in them. My code reaches for 17 outside services by name, among them email, cloud hosting, payments, texting, sign-in, a bank feed and social publishing. Thirty-eight of the 57 systems use at least one. Each service is an account in somebody's name, and when a builder leaves, the account either leaves with them or it was yours from the start.
The code also reads 375 different named settings from outside itself, such as keys and addresses, kept in 12 separate files that I counted and did not open. Twenty-seven background jobs on my laptop, some on a schedule and some always running, are defined in files that live outside every one of the 57 folders. The settings and the background jobs are the same lesson as the 50 things I have to keep alive, seen from the exit instead of from the inside.
Then there are the instructions. A README is the note at the top of a project that says what the project is. Forty-five of the 57 systems have one, 17 have a setup or operations document, and 8 have neither. Eighteen are not in a hosted code repository, which is an off-site copy of the code with its full history. For those 18 the only organized copy is on machines I control.

I do have one real test on record. On August 17, 2026 I rebuilt my entire server from a backup onto a blank machine. Every site was serving again in 3 minutes 19 seconds, all 8 applications started on their own, and a database pulled from off-site storage passed its built-in check for damage. The drill proves the system can move and does not prove a stranger could move it, because I was the one at the keyboard and I wrote the manual. The manual's own to-do list still says to run the drill with someone who has never seen the system.
My contract templates say you own it, and none of them says how you get it
All three of my contract templates give the client ownership of their data and content, and none of the three names a format, a deadline or a handover document. I read them clause by clause this morning against the four questions. All three are dated June 22, 2026.
| What the contract says | Website | Subscription | Project |
|---|---|---|---|
| You own your data and content | Yes | Yes | Yes |
| An export is promised when it ends | Yes | Content only | No |
| The export has a format and a deadline | No | No | No |
| You may keep running what was built | Yes, perpetual license | No, ends with the agreement | Yes, perpetual license |
| Outside accounts are in your name | Yes | No | No |
| A written handover is owed | No | No | No |
Seven of the 18 cells are a plain yes, and an eighth covers content only. The subscription template is the weakest of the three. It licenses the working parts only "while this Agreement is active," and it says the AI features are deactivated at the end of the paid period. A client on that template would leave with their content and without the thing they were paying for.
The second problem is simpler. All three templates were written for packages I stopped selling on September 23, 2026. What I sell now has no long-term contract and 30 days' notice either way, and the pricing page promises that your data stays yours, in writing. Every template does say the data is yours. None of the three was written for the current arrangement, and one still carries a six-month minimum that the current offer does not have. The note where I was supposed to work out what a client owns at the end has seven questions in it and one answer.
So the grade on my own shop is that the files are ready to leave and the paperwork is not. The table above is my list.
Three public kits are the part you can check without trusting me
Three free starter kits I publish are the one part of this audit you can check yourself, because everything else here is my own count of my own work. The three include the grocery planning kit, and this morning I downloaded all of them the way a stranger would. Together the kits are 150 files and every one is plain text, 129 of them ordinary notes. Each carries an MIT license, which lets anyone copy, change and reuse the work without asking me. Each download finished in under half a second and needed no account with me.
A handover should work the way that download did: a folder arrives, it opens, and the license says it is yours to use. Public kits prove the work can be taken. Nobody has yet shown they wanted to: the public counters on the three kits show zero copies taken and one bookmark.
Four questions about AI vendor lock-in to ask before you sign
These four questions are the whole audit, and a good answer to each one fits in a sentence.
- Is my data in a format I can open without you? A good answer names the format. Mine is 33 databases in one open file format and plain text for nearly everything else. "We can export it for you" is not a format.
- Can I keep running what you built, and does the contract say so? Ask whether the license survives the end of the agreement. Two of my three templates say it does and one says it does not, which is how I know to ask.
- Whose name is on the accounts? My systems lean on 17 outside services. Every service a client's system needs should be opened in the client's name on day one, because an account cannot be handed over as cleanly as a file.
- Is there a written handover, and when do I get it? Only 17 of my 57 systems have a setup document today, and none of my contracts promises one. Ask for the document and a number of days, in the contract, before the first invoice.
The model does not get a fifth question, because the answer is the same for every builder. The model is rented and it will be replaced. A builder who keeps the model's name in one place can move you in an evening.
No client has asked me for any of this yet. When one does, the answer should already be sitting in a folder with their name on it. After this morning I know which parts of mine are not.
Want this run for your business?
Book a free discovery call. We map where AI fits, show you the numbers, and point you to the right plan. No pressure, no jargon.
Book a Discovery Call →