Lock-in is not always the enemy. Sometimes the exit costs more than staying ever would. This is the thing nobody in the architecture conversation wants to say, because the default posture in engineering culture is that vendor dependency is inherently bad, portability is inherently good, and any sufficiently principled architect would never let it happen.
I've sat in the boardrooms of companies — a major insurer, an energy trading company, a reinsurer — where the engineering team was pushing hard for a migration away from a vendor, and the business case, when written down in full, didn't hold. The migration would cost more in engineering time, migration risk, and productivity loss than the vendor would ever charge in the remaining contract lifetime. The team knew it was locked in and found that intolerable. The numbers said: stay.
That's an uncomfortable truth to deliver. But it's the job.
How Lock-In Actually Happens
Lock-in is rarely the result of naivety. In most cases I've reviewed, the initial vendor decision was entirely rational. You chose Salesforce because your team had no bandwidth to build a CRM. You chose Snowflake because the analytics team needed a data warehouse in four weeks, not fourteen months. You chose Azure's managed Kubernetes because running your own control plane at that stage would have cost you two engineers full-time.
The lock-in came later — when the integration surface grew, when you built more internal tooling on top of vendor APIs, when your data gravity increased, when your team's institutional knowledge became tightly coupled to the vendor's specific abstractions.
At that point, you are not locked in because you made a bad decision. You are locked in because the vendor delivered real value, and real integration with valuable tools creates real switching costs. The switching cost is not the penalty for a mistake. It is, in many cases, the residue of success.
The lock-in taxonomy matters before you can price the exit
Not all lock-in is the same. Data lock-in (your data lives in a proprietary format or is hard to export at scale) is different from API lock-in (your code calls vendor-specific endpoints) which is different from skills lock-in (your team only knows this platform) which is different from commercial lock-in (you signed a multi-year contract with exit penalties). Each type has a different cost structure and a different mitigation path.
The Four Costs Nobody Fully Models
When an engineering team presents a "we should migrate off vendor X" proposal, the business case typically includes the target licensing cost and a heroic engineering estimate. It almost never includes the four costs that determine whether the migration actually pays off.
| Cost Category | What Gets Modelled | What Gets Missed |
|---|---|---|
| Engineering time | Feature work paused during migration | Parallel maintenance of old + new system, regression bugs |
| Data migration | Export and import of primary datasets | Schema transformation, validation, delta migration during cutover |
| Integration rework | Rewriting direct API calls | Downstream systems that assumed the old API's behaviour, edge cases |
| Organisational | Training on the new platform | Productivity dip during adaptation, support tickets, decision paralysis |
| Commercial | New vendor licensing | Early termination fees, minimum volume commitments, unused prepaid capacity |
| Risk | Sometimes zero | Production incidents during cutover, rollback complexity, customer impact |
The engineering estimate for a major platform migration is almost always wrong by a factor of two to three, in my experience. Not because engineers are bad at estimation, but because they scope the happy path. The migration cost model needs to include the unhappy paths: the integration that turns out to be undocumented, the data that doesn't export cleanly, the downstream service that breaks in a way you didn't anticipate.
A Real Case: The Data Platform That Wasn't Worth Leaving
An energy company I worked with had been using a proprietary data platform for operational and financial reporting for eight years. New engineering leadership arrived and immediately identified it as unacceptable lock-in. The platform was expensive — roughly €400,000 per year in licensing — and the vendor's roadmap had diverged from where the company needed to go.
The initial migration proposal was to replatform to a modern data lakehouse architecture: Azure Data Lake, Databricks, and dbt. The licensing cost would drop to approximately €160,000 per year. The engineering team estimated six months of work.
I was asked to review the proposal before approval. The full cost picture looked like this:
| Item | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
| Savings: licensing reduction | -€240,000 | -€240,000 | -€240,000 |
| Cost: 4 engineers, 18 months | +€900,000 | +€225,000 | — |
| Cost: data validation and parallel run | +€120,000 | — | — |
| Cost: productivity drag (50% for 18mo) | +€400,000 | +€200,000 | — |
| Cost: integration rework (7 downstream systems) | +€280,000 | — | — |
| Net | +€1,460,000 | +€185,000 | -€240,000 |
| Cumulative | -€1,460,000 | -€1,645,000 | -€1,405,000 |
Payback was at month 42. The current vendor contract ran for five more years, meaning the company would be spending four years in the red on the migration before year five began to recover it. The migration was not obviously wrong — over ten years it probably made sense. But it was not the financial slam-dunk the original proposal suggested.
The recommendation was to negotiate a better rate with the existing vendor (which produced a 22% reduction, yielding €88,000 per year in savings without a migration), invest the saved budget in building abstraction layers over the vendor API that would make a future migration less expensive, and revisit the migration decision in 18 months with a clearer product roadmap.
That recommendation was not popular. Engineers don't enjoy being told to stay in a house they've already decided to leave. But it was the right call.
When Leaving Is the Right Answer
I am not arguing that you should always stay. Lock-in is sometimes the genuine emergency it feels like. There are circumstances where the exit, even an expensive one, is the correct strategic decision.
The vendor is failing. If your vendor is financially distressed, being acquired by a competitor, or has announced end-of-life for the product you depend on, the question is no longer whether to leave, but how fast. The cost model changes entirely when the alternative is being stranded.
The vendor is extracting disproportionately. Some vendors use lock-in as leverage for pricing that exceeds any plausible efficiency argument for staying. If the annual increase is 30%, if the vendor has become unresponsive to contract negotiations, if you are paying significantly above market rate with no credible way to apply competitive pressure — leaving may be the only way to restore economic sanity.
The lock-in is preventing strategic moves. If staying with the vendor is blocking an acquisition, a regulatory requirement, a product direction, or a partnership that is materially more valuable than the migration cost — the calculus is different. Lock-in that forecloses optionality is more expensive than lock-in that merely constrains it.
The security or compliance posture has changed. If the vendor cannot meet a new regulatory requirement (NIS2, DORA, sector-specific data residency), there may be no viable alternative to migration regardless of cost.
Sunk cost is not a reason to stay
Be careful not to confuse "the migration is expensive" with "we should stay forever." The migration cost is the cost to exit — it does not make the status quo free. If the vendor relationship is genuinely broken, the right question is: what is the cost of staying for another five years, including strategic constraints and lost optionality? Sometimes that number is larger than the migration cost.
The Architecture Decision You Should Have Made Earlier
The honest conversation about lock-in is not the one you have when you're trying to leave. It's the one you should have when you're deciding to go in.
Most organisations could reduce their future switching cost significantly without sacrificing the value of the vendor relationship — if they made a few different decisions at adoption time.
The key principle is: use the vendor's proprietary value, but own your integration surface.
In practice that means:
Abstraction layers over vendor APIs. Write your internal code against an interface you control, not against the vendor's API directly. The vendor client becomes an implementation detail behind your interface. When you migrate, you swap the implementation — not the callers.
Own your data model. Store data in your canonical format first, then translate to vendor format at the boundary. When you exit, your data is already in your format. The export is trivial.
Document the lock-in explicitly. In every Architecture Decision Record where you accept a vendor dependency, write down what the switching cost is today, what would increase it, and under what circumstances you'd revisit the decision. This is not pessimism — it's a maintenance manual for the decision.
Negotiate data portability upfront. Before signing, get contractual commitments on data export format, API access for bulk data retrieval, and notice period for end-of-life. These terms are much easier to negotiate before the contract is signed than after you need them.
None of these fully eliminates lock-in. But they change the migration from a multi-year multi-million-euro rewrite to a planned, scoped project with a realistic timeline.
The Governance Question
The thing that surprises me most when I arrive at companies dealing with expensive lock-in situations is that the original decision was often made by a single engineer or a small team, without any architecture review, without any commercial analysis, and without any documented understanding of the switching cost they were accepting.
A vendor dependency decision at the platform level — database, data platform, identity provider, messaging backbone, cloud provider — is not a technical decision. It is a strategic and financial commitment that will constrain the business for years. It deserves governance proportionate to its impact.
That doesn't mean a committee review for every library. It means a lightweight but real decision process for platform-level choices: what is the annual cost, what is our exit cost today, what would make the exit cost worse, and who is accountable for this decision over time?
Without that process, you accumulate commitments nobody fully understands, and you arrive at the architecture review years later wondering how you ended up so deeply in one vendor's ecosystem. The answer is: one sprint at a time, without anyone counting.
If you're facing a vendor exit decision and the numbers aren't adding up in the way you expected, or you need a realistic migration cost model before committing engineering resources, let's talk — this is exactly the kind of decision a fractional CTO should help you make, not just validate after the fact.