The Hidden Cost of Software Lock-In — And How to Avoid It

Software lock-in is rarely the result of a deliberate decision. It accumulates gradually — through platform adoption, through integrations that deepen over time, through data that becomes harder to move the longer it sits in a proprietary format. By the time a business realises it is locked in, the cost of leaving has usually grown far beyond the cost of staying. Understanding how lock-in happens is the first step to avoiding it.

The Three Types of Lock-In

Lock-in takes several forms, and a business can face all three simultaneously.

Data lock-in is the most common. Your business data — customer records, transaction history, operational information — is stored in a format or structure that only the vendor's software can read. Exporting it gives you a flat CSV that loses relationships, history, and structure. Migrating to a different system means rebuilding years of data in a new format, which is expensive enough that most businesses simply do not do it. The data is technically yours; practically, it is the vendor's.

Contractual lock-in is explicit: minimum terms, exit penalties, notice periods measured in months, price increases that take effect mid-contract. SaaS agreements frequently contain auto-renewal clauses and price escalation provisions that businesses did not read carefully at signing. The contract itself creates the dependency.

Knowledge lock-in applies particularly to bespoke software. If the developer who built your system holds the source code, understands the architecture, and has not documented it, the cost of bringing in a different developer to maintain or extend it is prohibitive. The original developer becomes indispensable not because of the quality of their relationship with you, but because of what they know that nobody else does.

How Lock-In Becomes Expensive

The cost of lock-in is usually invisible until you try to exercise a choice you assumed you had.

SaaS price increases are the most common trigger. A platform adopted at one price point raises its rates — sometimes incrementally, sometimes dramatically following an acquisition. Businesses that have deeply integrated the platform into their workflows, trained staff on it, and accumulated years of data within it find that the cost of migrating substantially exceeds the cost of absorbing the price increase. The vendor knows this. It is reflected in their pricing power.

The acquisition scenario is related. A SaaS product is acquired by a larger vendor. The pricing changes, the product roadmap changes, or the product is discontinued in favour of the acquirer's competing product. Businesses that built critical workflows around the acquired product now face migration regardless of their preferences.

For bespoke software with knowledge lock-in, the trigger is typically the developer becoming unavailable — retirement, business closure, breakdown of relationship. At that point, the business discovers that what they thought was an asset they owned is actually a system only one person understands.

What Avoiding Lock-In Actually Requires

Avoiding lock-in is a structural decision, not a contractual one. It requires specific choices about where data lives, who holds the source code, and what the exit path looks like.

For bespoke software, the foundation is source code ownership: all code in a client-owned repository from day one, with a formal IP assignment in the contract. Every client I work with — NT Labs, Buxted Construction, Dugard — has their source code in their own GitHub organisation. If they chose to work with a different developer tomorrow, they could hand over the repository and continue. That is the only genuine form of no lock-in.

The data layer is equally important. Azure SQL is a standard relational database with documented query languages, standard export formats, and broad tooling support. Any competent database developer can read, query, and migrate an Azure SQL database. It is not a proprietary format; it has no vendor-specific syntax that only one platform understands. The data is portable in practice, not just in principle.

For integrations, the same principle applies: documented APIs, standard protocols, no proprietary connectors that only function with a specific platform. When an integration needs to change — because a third-party service updates their API, or because the client moves to a different accounting package — the integration can be updated without unpicking a proprietary dependency.

The SaaS Question

This is not an argument against SaaS categorically. Email, communication tools, project management — using SaaS for these is sensible. The lock-in risk is manageable because the switching cost, while real, is bounded. Moving from one email platform to another is disruptive but achievable.

The question is whether your core operational software — the system that holds your client relationships, your financial records, your operational workflows — carries the same bounded switching cost. For many businesses, the honest answer is that it does not. The system has become so embedded in daily operations that switching is theoretically possible but practically inconceivable.

That is not always a problem. Stability has value. The question is whether the dependency is chosen or accidental, and whether the business retains any negotiating position in the relationship. A SaaS product you could leave tomorrow — even if you choose not to — is a different position from one you genuinely cannot leave.

Assessing Your Current Position

A useful exercise: for each piece of software your business depends on operationally, answer three questions.

Can you export all your data in a usable format today? Not just the current state — the full history, in a form another system could import. Test it rather than assuming.

Do you have the source code, or can you get it? For bespoke or customised software, this determines whether you have an asset or a dependency.

What would actually happen if this vendor ceased trading or doubled their price? The answer reveals how much negotiating power you actually have.

The goal is not to be constantly switching software — that has its own costs. The goal is to be switching by choice rather than by necessity, and to maintain a negotiating position that reflects the value of your business relationship with your software providers. The relationships that last decades do so because both parties choose them. That requires both parties to have a genuine choice.

If you want to understand what a no-lock-in approach to your business software would look like in practice, get in touch.

Frequently Asked Questions

What is software vendor lock-in?

Vendor lock-in is when switching away from a software product or provider is prohibitively difficult, expensive, or disruptive — regardless of whether you want to switch. It can result from proprietary data formats (your data cannot be exported in a usable form), contractual terms (exit penalties or long notice periods), technical dependencies (integrations that only work with that vendor), or knowledge lock-in (only the vendor understands the system). The defining characteristic is that you have lost negotiating power.

How do I know if I'm already locked in to my current software?

Ask yourself: if this vendor doubled their price tomorrow, what would I do? If the honest answer is 'pay it', you are locked in. Practical indicators include: your data is in a proprietary format with no export option, your workflows depend on integrations the vendor controls, you do not have the source code if it's bespoke, or switching would require rebuilding years of historical data. Lock-in is usually invisible until you try to leave.

Can I export my data from SaaS software?

Usually yes, in some form — but the usefulness of the export varies. Most SaaS products offer CSV exports of current data. Few export the full history, audit trail, relationship structure, or custom configurations in a format that another system can readily import. The data may be technically yours but practically unusable without significant work to transform it. Before adopting any SaaS product, test the export function with real data and assess what you would actually get back.

What does 'no lock-in' actually mean in practice?

It means your data is in a standard format (Azure SQL, not a proprietary database), your source code is in your own repository (not the developer's), your integrations use documented APIs (not proprietary connectors), and there are no contractual barriers to stopping. You can take the system to a different developer tomorrow. You can export your data to a spreadsheet today. You can stop without penalty. These are specific, verifiable properties — not a marketing claim.

What should I ask a software developer about lock-in before signing?

Ask: Where will the source code be stored, and who owns it? What database technology will be used, and can I access it directly? What happens to my access if our relationship ends? Are there any contractual minimum terms or exit penalties? Can I see a sample contract? A developer who has genuinely structured their work to avoid lock-in will have clear answers to all of these. Vague answers are a signal worth taking seriously.

How does Azure SQL avoid database lock-in?

Azure SQL is Microsoft's cloud implementation of SQL Server — a standard relational database using documented T-SQL, standard ODBC/ADO.NET drivers, and broadly supported export formats. Any database developer can query it, export it, and migrate it to another system. It is not a proprietary format readable only by one vendor's software. Data stored in Azure SQL is portable in practice, not just in principle — which is what makes it the right choice for businesses that want genuine freedom of movement.

What does source code ownership actually mean day to day?

It means the source code for your system sits in a GitHub repository in your name, not the developer's. You can see every commit, every change, every decision made over the life of the project. If the developer relationship ends for any reason, you take the repository and hand it to a new developer. There is no negotiation required, no data export process, no dependency on the original developer's goodwill. Any competent C# and .NET developer can read the code and continue the work.

How do integrations create lock-in and how is it avoided?

Integrations create lock-in when they use proprietary connectors or middleware that only function with a specific platform. Avoiding it requires using documented, standard APIs — REST endpoints, published API specifications, standard authentication protocols. When a third-party service updates their API, a bespoke integration using their documented interface can be updated independently. A proprietary connector may require the platform vendor's involvement, on their timeline, at their price.

What are the three types of software lock-in businesses face?

Data lock-in is when your business data is stored in a proprietary format that only the vendor's software can read — exports are incomplete or unusable. Contractual lock-in is explicit: minimum terms, exit penalties, auto-renewal clauses, and price escalation provisions. Knowledge lock-in applies particularly to bespoke software where the developer holds the source code and understands the architecture, making replacement prohibitively expensive. Many businesses face all three simultaneously without realising it.

How do I assess my current lock-in exposure and what can be done about it?

Start by testing what you can actually get out of your current systems: export your data and see what you get back, ask your developer or vendor for the source code and see what happens. The answers tell you your real position. From there, the options range from negotiating better terms with your current provider, to commissioning a migration to a more portable system, to replacing a SaaS dependency with bespoke software you own. Get in touch to start the conversation.