How data, workflows, identity, and integrations can make leaving a connected product system harder than replacing one product.
One product can become a system
Switching costs are the losses a customer incurs when changing providers: migration work, retraining, downtime, contract exit, lost history, or a different workflow. Ecosystem lock-in is a particular form of that problem. Several products become connected through shared accounts, data, APIs, billing, permissions, or operating routines, so a decision about one component affects the others.
The phrase "layering" describes accumulation, not a guaranteed mathematical curve. A second product may reuse the same identity system and add little migration work; a third may connect to a bespoke workflow and add a great deal. The analyst must identify the dependencies and compare the cost of leaving with the benefit of staying.
What makes the cost accumulate
| Layer | Switching work | Important boundary |
|---|---|---|
| Data | Export, transform, validate, and preserve history | Some data may be portable while derived models or links are not |
| Identity and access | Recreate users, permissions, authentication, and audit trails | Standards can make this layer easier to replace |
| Workflow | Rebuild approvals, automations, training, and operating routines | Manual workarounds may keep a migration technically possible |
| Integration | Replace APIs, connectors, monitoring, and support arrangements | Open interfaces and common formats reduce dependence |
| Commercial | Terminate contracts, change billing, and absorb transition cost | Price and service quality can outweigh high migration cost |
A customer can therefore be locked in without being satisfied. The provider may retain the account because departure would interrupt payroll, reporting, or production, while a rival may still win if it can finance and manage the transition. Retention is an observation; it is not proof of an irreplaceable product.
Evidence from online brokerage
An empirical study of online brokerage customers measured switching costs and their relationship to retention. The study is specific to that industry and period, and its measures do not establish the mechanism in every software ecosystem. It is useful because it tests the concept against observed customer behavior rather than assuming that a broad product suite automatically creates lock-in.
In enterprise software, the same logic can be more operationally visible. A company that uses one provider for identity, collaboration, documents, analytics, and security may have to migrate permissions, connectors, archives, employee habits, and incident procedures together. The provider's advantage is strongest where these links are required for the customer's service, not where products are merely sold on one invoice.
Portability can change the economics
Lock-in is shaped by institutions as well as product design. The EU Data Act requires data-processing providers to support switching and portability and sets a timetable for reducing switching charges. The regulation does not make every application or workflow portable; it addresses defined data and service-provider obligations. It demonstrates that switching cost is not an immutable property of a technology market.
Standards, export tools, multi-cloud architecture, third-party consultants, and employee skills can perform the same function commercially. A provider may retain customers by making migration technically hard, contractually expensive, or operationally risky; a competitor or regulator can attack any of those layers.
Where ecosystem lock-in fails
A connected ecosystem can lose customers when the product deteriorates, an outage exposes a dependency, prices rise, or a new architecture makes the old integration unnecessary. Concentration can also create a common failure: one identity or control plane may disrupt many functions at once. A provider that monetizes lock-in without maintaining quality can turn retention into deferred churn.
Multi-product adoption can reflect procurement convenience rather than deep dependence. Conversely, a customer may buy separate best-of-breed products and still be highly locked in because the integrations were built internally. The relevant unit is the customer's operating configuration, not the vendor's catalogue.
What investors can test
- Map the dependency graph. Identify which products share data, identity, workflows, interfaces, and support.
- Estimate a real migration. Include people, downtime, consultants, validation, contract exit, and the period when both systems must run.
- Check portability. Test export formats, API limits, derived data, permissions, and whether an alternative can reproduce the customer's process.
- Separate retention from satisfaction. Look for usage, service incidents, pricing, expansion, churn after migrations, and customer references.
- Watch the counterforce. Standards, regulation, open-source tools, and a rival's migration funding can lower the accumulated cost.
Ecosystem lock-in is strongest when the provider's components jointly perform a necessary customer function and the connections are costly to recreate. It is weaker when the links are cosmetic or portable. Following each dependency makes the difference visible without pretending that every large platform is an unavoidable one-way door.
Inside CompanyGraph
CompanyGraph tracks one recurring-earnings shape live: net income carried by continuing operations and exceeded by operating cash flow, with depreciation passing through at the scale of a mature installed business.
Recurring Earnings Configuration
Continuing-operations is large or larger than total net income, OCF exceeds net income, and depreciation is large relative to OCF
The shape is consistent with retained, recurring demand. It cannot show renewal rates, contract terms, or the switching costs themselves; those live outside the statements.