The hidden cost of vendor lock-in.

A founder we worked with in early 2025 had been on a popular CRM for four years. The annual cost had drifted upward, the product had drifted in directions the firm did not need, and a competitor had quoted a number forty percent lower for the same use case. The founder decided to switch. Eight months later, the firm was still on the old CRM. The switch had not failed for any single dramatic reason. It had failed in five small ways at once, and each of the five had cost more time than it should have.

This is what vendor lock-in actually looks like. Not "you cannot leave". The phrase that captures it is, "leaving will cost six months of your attention you do not have to spare". The cost is real, the pattern is predictable, and the time to look at it is before the contract is signed.

Pattern one: data export that is technically true and operationally useless

Almost every SaaS contract promises data export. The promise is true. The CSV that comes out is also true. What the CSV does not contain is the relational structure: which contact belonged to which account, which note attached to which deal, which custom field mapped to which workflow, which deleted record had children that still exist. The data lands in the new system as flat lists. The team spends a month re-stitching it.

The diagnostic before signing is simple. Ask the vendor for a sample SQL dump of a demo tenant, with the schema documented. If the response is "we provide CSV export", the data is locked even though the contract says otherwise. The firms that get this right insist on either a SQL dump or a structured JSON export with foreign-key references intact, written into the contract before signing.

Pattern two: custom workflows that exist only inside the vendor's UI

Over the years on a SaaS product, the team builds the firm's operational shape into the product's configuration. Custom fields. Pipeline stages. Approval rules. Automation triggers. Email templates. Report definitions. Each one was added to solve a real problem. Each one is invisible until the firm tries to leave.

Migrating these workflows to a new vendor is not a data problem. It is a translation problem. The new vendor's configuration model is different. The translations are manual. The translations are also the institutional memory of how the firm runs, which means losing them is worse than losing the data.

The pattern we saw at AKSD before the WooCommerce-plus-custom-ERP architecture was settled was exactly this. Years of plugin configurations and theme customisations sat between the firm and any straightforward migration. The decision to build the operational layer custom, and treat the storefront as the swappable surface, was made specifically to avoid recreating the lock-in elsewhere.

Pattern three: integrations that only the vendor offers

The SaaS pitch usually includes a marketplace of integrations. Accounting, telephony, shipping, payment, e-signature. Each integration is built by the vendor or its partners. Each integration expects the vendor's data shape at one end. When the firm moves to a new vendor, every integration has to be rebuilt against the new vendor's API, or replaced with a different product entirely.

The number of integrations is the silent multiplier on switching cost. A firm with two integrations can move. A firm with eleven integrations cannot, practically, move within a year of founder attention. The integrations themselves did not lock the firm in. The quantity of them did.

Before signing, the question to ask is not whether the vendor offers the integrations the firm needs. It is what the firm's exit plan looks like for each integration. If the answer is "we would build it ourselves on the new platform", the exit cost is bounded. If the answer is "we depend on the marketplace", the exit cost is unbounded.

Pattern four: UI training that is product-specific, not workflow-specific

When the team has spent two years inside a SaaS product, the muscle memory is for that product's interface. The screen layouts. The keyboard shortcuts. The terminology. The "right" sequence of clicks to complete a common task. Moving to a new product means re-training twenty or fifty people, and during the training period, productivity dips for everyone simultaneously.

This is the cost founders consistently underestimate. The product itself can be switched in a weekend. The team's relationship with the product cannot. A focused operational system that mirrors the firm's actual workflow, rather than the vendor's notion of how the workflow should look, sidesteps this cost in two directions. Less to relearn when the system evolves, because the system is the firm's. Nothing to relearn when the surrounding tools change, because the system is independent of them.

Pattern five: billing structures that make leaving expensive even if everything else works

The fifth pattern is the most cynical. Annual contracts that auto-renew. Multi-year discounts that lock in pricing in exchange for a heavy mid-contract exit penalty. Per-user seat costs that extend past the active user count for the remainder of the term. Data retrieval fees on exit. Migration assistance billed at the vendor's professional services rate.

None of these is unusual. All of them are negotiable before signing, and almost none of them is negotiable after. The leverage the firm has on day one is the leverage the firm should use. The leverage on day eight hundred is far smaller.

What to evaluate before signing

The pre-contract evaluation that prevents the eight-month switch disaster has five questions, one per pattern. The questions are not adversarial. They are clarifying.

What is the data export format, and can you show me a sample with schema documentation. What configuration migrates with us, and what becomes a re-build. Which integrations are vendor-specific, and what does our exit plan look like for each. What does training look like for a team of our size, and how long until productivity recovers. What are the contract terms on auto-renewal, exit fees, and data retrieval.

A vendor that answers all five honestly is a vendor the firm can work with. A vendor that deflects is showing the firm exactly what the eight-month switch will look like, three years from now.

The architectural alternative

The pattern that avoids all five forms of lock-in is structural, not contractual. Build the operational system inside the firm's infrastructure, with the firm's data, against the firm's workflows. Keep swappable products at the edges (storefront, payment, shipping, accounting), where the integration shape is well-defined and the substitution cost is bounded. The firm holds the substrate. Vendors provide commodities.

This was the architecture chosen for Carbiforce, Metaldur, and Kawacut. Three brands, shared ownership, isolated tenants, custom workflows, all on infrastructure the firm controls. The annual subscription that the firm previously paid to a SaaS CRM is gone. The configuration the team built up over years lives in code that the firm owns. The integrations are bounded. The exit cost is bounded by construction, because no exit is required.

The longer treatment of the build-versus-buy math sits in this essay. For founders inside the lock-in question right now, the work we do under the internal systems practice is structured to move firms from rented operational systems to owned ones, on a timeline that respects the day-to-day operation.

Decision infrastructure that the firm owns does not lock the firm in because there is no one to lock the firm in. The system serves as long as it serves. The firm decides when, and how, to evolve it.

If lock-in is the cost you have started seeing on your current stack, the conversation worth having is about the substrate. Start a Conversation.