Vendor lock-in is a reversibility problem, not a vendor one
Vendor lock-in is about reversibility, not vendors. A test for each dependency: what leaving would take, how much is your data versus their behaviour.
AWS will pay your exit bill. Since March 2024 it has offered free data transfer out to the internet when you move out of AWS, waiving data transfer out charges for customers leaving the platform — a policy it says "follows the direction set by the European Data Act". The most-quoted cost of vendor lock-in is the one the vendor is willing to zero out, which tells you the expensive part was never the bytes.
This post is the test we apply on architecture engagements: for each dependency, what would it actually take to leave, how much of it is your data versus their behaviour, and when buying lock-in deliberately is the right call. It ends with the uncomfortable answer that some of your dependencies should stay locked in.
Vendor lock-in is a reversibility problem, not a vendor problem
Every production system depends on vendors. The useful distinction is not between dependent and independent architectures, because the second does not exist — it is between decisions you can unwind and decisions you cannot. The New Stack puts it well: the risk is not relying on vendors, it is dependencies that become too expensive or impractical to unwind, and limits on flexibility "rarely trace back to a single vendor; more often, they hinge on how reversible the team's past decisions are."
That reframing matters because it changes what you argue about. "Should we use a managed service?" has no general answer. "How long would it take us to stop using this one, and who would have to do the work?" has a specific one, and you can write it down at the moment you make the decision, when you still know why you made it.
The counter-argument deserves its strongest form: reversibility is not free. An abstraction layer you build to stay portable is code you maintain forever, and if you never run it against a second implementation, it is lock-in with extra steps and a worse debugging story. Teams that optimise for portability up front routinely ship slower and end up just as stuck, because the coupling that trapped them was in the operational model, not the API surface.
The three questions to ask about every dependency
We ask the same three things about each external dependency in an architecture review, and we ask them at the decision, not at the migration:
- What would it take to leave? Not "is there an alternative" — name the work. Which services change, which team does it, over how many weeks, and what breaks while it happens.
- How much of this is our data, and how much is their behaviour? Data comes back. Behaviour has to be rebuilt, and rebuilding behaviour is where migrations overrun.
- What happens if they change, not if they die? Vendors rarely disappear. They reprice, deprecate, relicense or get acquired. The New Stack's version of this test is sharper: "if a vendor disappeared tomorrow, or was ordered to stop serving you, what still runs next month?"
Question three is not hypothetical. In August 2023 HashiCorp changed Terraform's licence from the Mozilla Public License to the Business Source License, and the community forked the last MPL-licensed code into OpenTofu, now a Linux Foundation project under the MPL 2.0. Nobody's Terraform stopped working that week. What changed was the terms, and teams that had built businesses on top of it had to decide under someone else's timetable.
Your data versus their behaviour, across four real dependencies
The second question is the one that does the work, because the ratio varies enormously and almost nobody checks it before committing. Four dependencies, ordered from mostly-data to entirely-behaviour:
| Dependency | What exports cleanly | What you rebuild |
|---|---|---|
| Managed relational database | Schema, rows, indexes — a dump is a dump | Failover semantics, point-in-time recovery windows, connection pooling behaviour, proprietary extensions your queries assume |
| Auth provider | User records, and sometimes the password hashes | Session and token semantics, MFA enrolments, social-login links, and every user identifier your tables use as a foreign key |
| Proprietary message queue | Almost nothing — messages are in flight | Ordering guarantees, deduplication windows, visibility timeouts, dead-letter behaviour: assumptions baked into every consumer |
| AI model API | Your prompts, evaluations and tool schemas | The model's actual behaviour, which you cannot export and the vendor controls the lifetime of |
Read that table as a gradient and the strategy falls out of it. The managed database is the reversible end: painful, expensive, and genuinely finite, with the sharp edge being the proprietary extensions and stored logic rather than the data. Anyone who has costed an Oracle to MariaDB migration knows the port is in the procedural code, not the tables.
The auth provider is where teams get surprised. Exporting users is the easy half. The hard half is that the provider's user identifier is probably a foreign key in thirty of your tables, in your audit log, and in URLs your customers have bookmarked. That is not a vendor problem; it is a schema decision you made on day one and can still fix today by minting your own internal user ID and treating the provider's subject claim as an external reference.
The queue is the clearest case of pure behavioural lock-in. There is no data to migrate at all, and yet swapping it is often harder than swapping the database, because the guarantees are encoded implicitly across every consumer, undocumented, and only discovered when they stop holding.
The model API sits at the far end. There is no data. There is a behaviour you tuned against, and the vendor sets its lifetime — as anyone who worked through the GPT-4 shutdown on 23 October can confirm. The reversibility work here is unusual: it is not an abstraction layer, it is an evaluation suite. If you have a scored test set that tells you within a day whether a different model is good enough, you are reversible. If your only measure is that it seems to work, you are locked in regardless of how clean your client library looks, however tidy the wrapper around it is.
When paying for lock-in is the correct call
Sometimes the right decision is to take the dependency, accept that leaving would hurt, and write the number down. We would argue for that in four situations:
- The dependency is not on the path of the change you might need to make. If the business pivot you can imagine does not touch your transactional email provider, its portability is not worth engineering time.
- Speed is the only risk that matters right now. A pre-revenue product has one failure mode, and it is not being stuck on the wrong queue in 2029. Managed everything is usually correct until there is something to protect.
- The exit cost is bounded and known. "Six engineer-weeks and a weekend of degraded service" is a decision. "We have no idea" is the thing to fix, and fixing it costs a day of investigation, not a rewrite.
- The alternative is an abstraction nobody will exercise. A portability layer with one implementation is a liability. If you are not going to test it against a second backend, buy the managed service and keep the code simpler.
Where we would argue the other way: anything holding data you are legally required to be able to move or keep in a jurisdiction, anything that would block a customer's deployment model, and anything whose vendor could reprice it without you having a credible response. Those are the dependencies that turn into the true cost of poor software architecture, where the problem only becomes visible once it is expensive.
Test the exit the way you test restores
An exit plan you have never executed is the same artefact as a backup you have never restored: a document that makes people feel safe. The New Stack calls the property exit velocity — how fast a workload can actually move — and notes that it "only means something when you test it on a schedule, as earlier generations tested disaster recovery." That is the right comparison, and the right cadence.
What that looks like in practice, and none of it is exotic:
- Restore the production database onto a different engine or provider in a staging environment, once a quarter, and record how long it took and what broke.
- Keep one service deployable to a second target, even if it never runs there, so that the build and configuration assumptions stay honest.
- Run your model evaluation suite against an alternative model on a schedule, not during an incident.
- Put the exit cost estimate in the same document as the price whenever you adopt something new, and revisit it when the contract renews.
Two caveats worth stating. Multicloud is not the answer to this and rarely pays for itself — Form3 ran on three clouds and now says don't, and we agree for most teams. And open source is a better starting position, not a guarantee: as The New Stack notes, a team can still build tight coupling on open foundations. What open licensing buys you is that inspection is a property you hold rather than a permission that can be withdrawn.
The number that belongs in every vendor decision
The reason AWS can afford to waive egress on the way out is that egress was never what kept anyone. It also gives every customer 100 GB of data transfer out free each month aggregated across all services and regions, so for most workloads the bill was small to begin with. The retention comes from the IAM model, the managed services, the operational habits and the forty integrations nobody wants to re-point.
So use the vendor's generosity as the diagnostic it is. If a provider will happily pay for you to take your data, ask what they are confident you will leave behind. The answer is your real exit cost, and the discipline of writing it down at purchase — the same discipline that avoids a surprise when one developer left Google Play — is most of what separates teams that can change direction from teams that have to negotiate for permission. If you want that assessment run properly across an estate, that is the work our custom software development practice does.
Frequently asked questions
You do not avoid vendor lock-in entirely, because every production system depends on vendors. You manage it by scoring each dependency for reversibility: name the work leaving would take, separate your data from the vendor's behaviour, and test the exit on a schedule rather than during an incident.
No. Buying lock-in is correct when speed is your dominant risk, when the dependency sits off the path of any change you can foresee, or when the alternative is a portability abstraction nobody will ever exercise. The requirement is that you know the exit cost, not that it is zero.
Less in egress than people assume. AWS has waived data transfer out charges for customers migrating off the platform since March 2024, and gives 100 GB of free monthly transfer out anyway. The real cost sits in identity, managed services and integrations that have to be rebuilt.
The ones that are mostly behaviour rather than data. A proprietary message queue holds almost no data, yet its ordering, deduplication and dead-letter guarantees are encoded implicitly across every consumer. An AI model API is harder still, because the behaviour cannot be exported at all.
It improves your position without guaranteeing anything, since a team can still build tight coupling on open foundations. What open licensing changes is that inspection becomes a property you hold rather than a permission a vendor grants, and permissions can be withdrawn.
Treat exit velocity the way earlier generations treated disaster recovery: on a schedule. Restoring production data onto a second engine once a quarter, and recording how long it took and what broke, converts an exit plan from a document into a measured capability.
