"What happens if we want to leave?" Comes up in every enterprise sales conversation, usually by the second meeting. The client has been burnt before, or heard the stories. A vendor who held their data hostage. A platform that made migration prohibitively expensive. A proprietary system where leaving meant starting from scratch.
What You Need to Know
- Some degree of lock-in is unavoidable in any technology decision. The question is whether it's acceptable or dangerous
- Dangerous lock-in is when your vendor controls your data, your business logic, or your ability to operate without them
- Acceptable lock-in is when switching costs are proportional to the value received and migration is technically feasible
- The best protection against dangerous lock-in is architectural decisions made at the start, not contractual clauses added at the end
Lock-In Is a Spectrum
Zero lock-in doesn't exist. Every technology choice creates some degree of switching cost. Choosing React means your front-end developers need React skills. Choosing AWS means your infrastructure uses AWS services. Choosing a specific database means your data model reflects that database's capabilities.
The question isn't "how do we avoid lock-in?" That question leads to paralysis or to bland technology choices that avoid commitment. The question is "what lock-in is acceptable, and what lock-in is dangerous?"
The Dangerous Kind
Data Lock-In
The most dangerous form of lock-in is when a vendor controls your data in a format that makes extraction difficult or impossible. Proprietary data formats. Undocumented schemas. Export tools that produce incomplete or lossy outputs.
Your data is your most valuable digital asset. If you can't get it out of a system in a complete, structured format at any time, you have a serious problem. This is non-negotiable.
First question in any vendor evaluation: can I get all my data out tomorrow in a format I can use? If the answer is anything other than an unqualified yes, walk away.
Hassan Nawaz
Senior Developer
Business Logic Lock-In
When your business rules, workflows, and processes are encoded in a platform's proprietary configuration rather than in code you own, leaving that platform means rebuilding all of that logic from scratch. You're not just migrating data. You're re-implementing years of operational knowledge.
Low-code and no-code platforms are particularly susceptible to this. The promise is rapid development. The trade-off is that the logic you build is expressed in the platform's proprietary model, not in portable code.
Skill Lock-In
When a system requires specialist skills that only the vendor (or a very small number of partners) can provide, you're locked in through your workforce. SAP is the classic example. Qualified SAP consultants command premium rates because the supply is constrained and the demand is persistent.
The Acceptable Kind
Infrastructure Lock-In
Using AWS Lambda functions creates lock-in to AWS. Using Azure Functions creates lock-in to Azure. This is generally acceptable because the switching cost is known, the migration path is clear (rewrite the functions for the other platform), and the value received (managed serverless infrastructure) is proportional to the switching cost.
The mitigation is straightforward: keep your business logic separate from your infrastructure layer. If your domain logic is in well-structured, platform-agnostic code that happens to be deployed on AWS, moving to Azure is a deployment exercise. If your domain logic is scattered through AWS-specific services, moving is a rewrite.
Framework Lock-In
Building your front-end in React creates lock-in to React. This is acceptable because React skills are abundant, the migration path to alternatives (Vue, Angular) is well-understood, and the value received (productive development, large ecosystem) justifies the switching cost.
Vendor Relationship Lock-In
When you've worked with a development partner for three years and they understand your domain, your systems, and your team, there's a switching cost to changing partners. This is the healthiest form of lock-in because it's based on mutual value, not on artificial barriers.
Architectural Protection
The best protection against dangerous lock-in is architectural, not contractual. Contracts can require data portability, but architecture makes it natural.
Own Your Data Layer
Use standard databases (PostgreSQL, SQL Server) with well-documented schemas. Ensure you can query and extract your data independently of the application layer. If the application disappeared tomorrow, your data should still be accessible and useful.
Separate Concerns
Keep business logic in application code, not in platform configuration. Keep infrastructure configuration in declarative files (Terraform, CloudFormation), not in console click-trails. Keep integration logic behind abstraction layers that can be re-pointed to different systems.
Use Open Standards
REST APIs over proprietary protocols. Standard data formats (JSON, CSV, XML) over proprietary exports. Open authentication standards (OAuth, SAML) over custom auth mechanisms. Every open standard you adopt is a migration path you preserve.
Document Everything
When a vendor builds a system for you, the documentation should be thorough enough that a different team could maintain and extend it. If the only people who understand how the system works are the people who built it, you have documentation lock-in.
The Honest Answer
When clients ask us about lock-in, we're direct. Working with RIVER creates some lock-in. We build on open standards and standard technology stacks, so switching to another development partner is technically feasible. But we understand your domain, your systems, and your team. That understanding has value, and losing it has a cost.
What we commit to: your data is always yours, in standard formats. Your code is always yours, in standard languages. Your infrastructure is documented and reproducible. If you choose to leave, the transition is practical, not punitive.
That's the line between vendor lock-in and vendor value. One traps you. The other earns your continued business by being worth it.