“Built on open source” has become a reassurance that doesn’t reassure. It’s true of nearly every provider now, and it tells you almost nothing about whether you could leave one.
The licence was never what trapped anyone. These seven things are, and a provider can have every one of them while running entirely open source underneath.
None of this requires bad intent. It’s what happens by default when a company optimises for its own operations. The effect on you is identical either way.
1. The control plane isn’t the hypervisor
The hypervisor is open. The thing you actually operate it with — the portal, the orchestration layer, the automation that makes it a product rather than a pile of servers — frequently isn’t.
This is the most common form and the least visible. You can verify KVM underneath and still be entirely dependent on a control plane that exists nowhere else.
Test for it: ask what the control plane is, by name and version. “Upstream OpenStack 2026.1” is an answer. “Our platform” is a different answer.
2. API extensions your automation quietly adopts
A provider offers the standard API plus a handful of useful extras. Your team uses the extras, because they’re there and they’re useful.
Eighteen months later your Terraform is full of resources that only exist in one place. Nobody decided to depend on them. Everybody did.
Test for it: ask which API endpoints are non-standard. Then check whether your automation touches them.
3. Portal-first configuration
Everything is configurable, as long as someone is clicking. There’s an API, but the real workflow is the interface, and the interface is where the knowledge lives.
The lock-in here isn’t technical, it’s organisational. When configuration exists as a sequence of clicks somebody remembers rather than as code somebody can read, it can’t move — because there’s nothing to move.
Test for it: can you rebuild your entire environment from a file in your own repository? If not, you don’t have a configuration. You have a habit.
4. Undocumented build
The cluster works. It’s been tuned. Somebody made good decisions about failure domains and cache modes and network topology, and those decisions are in that person’s head at the provider.
You could take the hardware and the software and still not be able to run it, because what made it work was never written down. This is the quietest form of lock-in and the hardest to detect, because everything appears fine right up until you need someone else to take over.
Test for it: ask for the build documentation. Not the user guide — the build. If it doesn’t exist, you’re depending on continuity of staff at a company you don’t control.
5. Egress priced as a deterrent
Bandwidth at scale does not cost what it’s charged at. When the rate is set well above cost on the one dimension that measures leaving, that rate is doing a job, and the job isn’t cost recovery.
Pulling a petabyte out of a hyperscaler runs into six figures in transfer charges alone. That isn’t a technical obstacle. It’s a price set to make the rational decision be staying, independent of whether staying is right.
Test for it: calculate what it costs to move all your data out today. If the number changes your mind about leaving, that was the point.
6. No defined exit
Nobody wrote down what leaving involves. So leaving starts as a discovery project you have to fund and scope before you can even estimate the real thing.
That uncertainty is itself the lock-in. A migration you can price is a decision. A migration you can’t price is a risk, and risks get deferred indefinitely.
Test for it: ask what happens if you leave. A provider who has thought about it will describe formats, timelines and a process. A provider who hasn’t will describe how unlikely it is that you’d want to.
7. Data gravity you were encouraged to build
The subtlest one. Managed databases, proprietary queueing, a bespoke identity integration, an event bus that only exists here. Each was individually a good decision — faster to build, less to operate.
Collectively they mean the workload isn’t portable even though the VMs are. You can move the compute. You can’t move the thing the compute depends on.
Test for it: list every managed service you consume that isn’t a standard open-source project you could run yourself. That list is your migration scope, and it’s usually longer than anyone expects.
What good looks like
The inverse of each:
| Lock-in mechanism | What to require instead |
|---|---|
| Proprietary control plane | Named upstream distribution and version |
| API extensions | Standard endpoints, extensions documented and optional |
| Portal-first config | Everything expressible as code you hold |
| Undocumented build | Build documentation delivered to you |
| Punitive egress | Rate agreed in the contract before signing |
| Undefined exit | A written exit process, with formats and timelines |
| Proprietary managed services | Standard projects you could run elsewhere |
The test that cuts through all of it
Ask a prospective provider one question:
“Show me the documentation for migrating off you.”
The answer tells you everything. Some providers have it and will send it. Some have never been asked and will improvise. Some will explain why you’d never want to, which is its own answer.
It’s a fair question and it isn’t hostile. Any supplier of anything important should be able to describe what ending the relationship looks like. In infrastructure the question is unusual only because the industry has been allowed to treat it as unusual.
Why we care about this more than most
We publish our exit documentation in the same place as our onboarding documentation, and we’d rather a customer stayed because leaving would be a bad idea than because it would be hard.
That’s a commercial position, not just an ethical one. A provider who has to make leaving painful is telling you what they think of their own product. We’d rather compete on whether the infrastructure is good.
It also isn’t costless. It means we can’t rely on friction to hold accounts, and every renewal is genuinely a decision. That’s the trade, and we think it’s the right one — but we’d rather say plainly that it’s a trade than pretend it’s pure altruism.
Frequently asked questions
No. The licence guarantees you can use and modify the software. It guarantees nothing about whether your specific deployment, configuration and data can move somewhere else with reasonable effort.
Work through the seven tests above. The fastest three: ask for the build documentation, calculate your full egress cost, and check whether your automation depends on non-standard API endpoints.
Usually, yes. Every real decision creates some dependency. The question is whether you chose it knowingly and priced it, or acquired it by default and discovered it at renewal.
They have written down how to leave, and they’ll give it to you before you sign.