59% of German companies say the biggest obstacle to changing cloud provider isn’t price or features — it’s the difficulty of getting their data out. Which means the most important thing to test about a vendor is the thing almost nobody tests: the exit.
Read those three together. Costs going up, a stated preference for something different, and the most-cited obstacle is not the quality of the alternatives — it is the door.
Lock-in is not a decision anyone made
That is what makes it hard to argue about. Nobody sits in a meeting and chooses to become dependent. It accumulates.
One integration written against a proprietary interface because that was the fastest route. One export format nobody examined because there was no reason to. One “we’ll deal with that later” about the audit history. Three years on, the sum is a project rather than a choice, and the renewal conversation happens without leverage.
The asymmetry is worth naming: entering is designed, resourced and celebrated. Leaving is unplanned, unfunded, and usually attempted under time pressure by whoever is left.
Four kinds of lock-in
They need separate answers, and conflating them is why “can we export our data?” is such a weak question.
Data lock-in. Your content is held in a format nothing else reads, or the export omits the parts that carry the meaning. This is the one everyone thinks of, and often the easiest to solve.
Integration lock-in. Twelve internal systems now call the vendor’s interface. Each one is small; together they are the migration. This is usually the largest hidden cost and it grows quietly.
Operational lock-in. Your team knows this system. The runbooks, the conventions, the folder structure, the tacit knowledge of which quirks to work around. Nobody writes this down and it does not appear in any inventory.
Contractual lock-in. Multi-year terms, discounts contingent on commitment, notice windows that only open once a year. Legal rather than technical, and frequently the binding constraint.
The exit test
This takes an afternoon and is the single most informative thing you can do in an evaluation. Do it while you still have leverage — during the trial, not at renewal.
Run it, don't read about it
- Request a full export through the documented path. Note whether it is self-service or requires a support ticket. A ticket is a finding.
- Time it. At your real data volume, not the demo dataset. Extrapolate honestly from the trial size.
- Open what comes out. Not the file listing — the actual content. Can a person read it? Can another system import it?
- Count what's missing. Permissions, version history, comments, audit logs, metadata, attachments. Compare against what you'd need to reconstitute the system elsewhere.
- Ask what happens next. How long does the vendor retain your data after cancellation, and what is the deletion evidence?
Then write down four numbers: how long the export took, what fraction of the content survived it, how many internal systems would need changing, and how many days the migration would take with a named person owning it.
Those four numbers are your actual switching cost. Most organisations have never calculated them, which is precisely why 59% experience lock-in as an insurmountable obstacle rather than a quantified one. It is often smaller than feared — and occasionally very much larger, which is worth knowing before signing rather than after.
Where self-hosting changes the question — and where it doesn’t
Running the software on your own infrastructure removes two things. The data-custody problem disappears, because the material is already on hardware you control and there is no export to request. And the scenario where a vendor’s commercial decision strands you disappears, because nobody can switch off a system running in your own environment.
It does not remove format lock-in, integration lock-in, or operational lock-in. A self-hosted system with a proprietary schema and twelve internal integrations is still a migration project. The honest framing is that self-hosting changes who holds the timing: you can take as long as you need, because the clock is not being run by someone else’s renewal date.
That is a meaningful difference and it is not the same as freedom. Any vendor — us included — who presents self-hosting as an escape from lock-in is performing the same trick in the opposite direction. The related economics are in the real total cost of self-hosted RAG; this article is deliberately about portability rather than cost.
Four questions before you sign
- What is the export format, and has anyone on our team actually run the export?
- How long would a full migration take, in days, with a name attached to it?
- What breaks if the vendor changes its terms, or is acquired?
- Could we run this on our own infrastructure if we decided to?
If the answer to the last one is no, you do not have an exit. You have a hope — and hope is a fine thing to have in a supplier relationship, just not the only thing.
Frequently asked questions
What did the Bitkom Cloud Report 2026 say about switching?
Among companies that have not changed cloud provider, 59% named lock-in effects — the difficulty of exporting data and migrating — as the biggest obstacle. The same report found cloud operating costs rose for 64% of companies in the preceding year, with a majority expecting further increases, and that 91% would prefer a German provider while 53% have one. Rising costs, a stated preference for something else, and the most-cited obstacle being the door rather than the alternative.
Isn't an export feature enough?
Having one and having run one are different states of knowledge. The questions that matter are what format it produces, how long it takes at your data volume, what it silently omits — permissions, version history, comments, audit logs and metadata are the usual casualties — and whether anything downstream can actually read it. An export that produces a proprietary archive nobody else imports is a compliance checkbox, not an exit.
Does self-hosting eliminate lock-in?
No, and it is worth being blunt about this. Self-hosting removes the data-custody problem — the material is already on your infrastructure — and it removes the scenario where a vendor's commercial decision strands you. It does not remove format lock-in, integration lock-in or the operational knowledge your team has built up. What it changes is who holds the timing: you can take as long as you need, because nobody can switch you off.
How often should we run the exit test?
Once during evaluation, and then at each renewal. Both matter for different reasons: during evaluation because it is the only moment you have real leverage, and at renewal because export paths quietly rot — formats change, volumes grow, and the person who knew how it worked has left.
What about the AI-specific parts — do embeddings and indexes matter?
Less than people fear. The processed artefacts of a retrieval system — the numerical indexes built from your documents — are regenerable from the source material and rarely worth migrating. What matters is the source documents, the access-control model, the conversation and audit history, and any content people have curated inside the tool. Ask specifically about those four; a vendor who offers to export the indexes but not the audit trail has answered the easy question.
Sources & further reading
- Bitkom — Cloud Report 2026 (press release, 17 June 2026) — 603 German companies, 20+ employees; the 59% lock-in and 64% cost-rise figures
- Bitkom — Cloud Report 2026 (full study) — methodology and full question set