Vendor Lock-In: What It Is and How to Get Out of It

Vendor lock-in means a company cannot leave a software or cloud provider without high cost, data loss or disruption. It happens when data, workflows and integrations depend on one provider’s proprietary technology and contract terms. The way out is a planned exit: a dependency inventory, a full data export, a parallel run and, where it pays off, owned software.

Subscribing to a SaaS product takes a credit card and an afternoon. Leaving it can take a year. Over time, the tool collects years of records, custom fields, automations and integrations that nobody fully documented, and the price of switching grows quietly with every month of use.

This guide explains what vendor lock-in is, how SaaS products create it, how to spot it early and how to reduce it. It also covers the rights European law now gives companies that want to switch, and when owning the software is the most reliable way out.

Key takeaways

• Vendor lock-in builds up through four dependencies: data, processes, integrations and commercial terms.
• SaaS lock-in is stronger than lock-in with installed software, because the company holds neither the code nor the infrastructure.
• GDPR Article 20 gives data portability to individuals; the EU Data Act gives business customers the right to switch cloud and SaaS providers.
• Under the Data Act, notice to switch is capped at two months, and switching and egress charges are removed from 12 January 2027.
• A legal right to an export does not move the processes; mapping, cleaning, a parallel run and decommissioning remain a project.
• Owning the software is the most complete exit, but only when the three-year numbers support it for each tool.

What is vendor lock-in?

Vendor lock-in is dependence on one provider that makes switching too expensive, too risky or too slow to be practical. Leaving simply costs more than staying, so it stays, even when the product no longer fits or the price keeps rising.

Lock-in rarely comes from one decision. It builds up through four kinds of dependency:

Some lock-in is acceptable. A commodity tool that works, costs little and has standard exports is not a risk worth managing. The problem starts when the dependency covers core processes and business data, and nobody can say what leaving would cost.

How does SaaS vendor lock-in build up?

SaaS vendor lock-in is stronger than lock-in with installed software, because the company holds neither the code nor the infrastructure. The provider controls where the data lives, in what format it can leave and how much the next renewal will cost.

• Data gravity. Every year of use adds records, files and history. The more data sits in the product, the harder a complete and verified export becomes.
• Custom workflows. Teams configure fields, statuses, approval chains and automations in the vendor’s own builder. That logic is rarely documented outside the product, so it has to be rediscovered before it can be rebuilt.
• Integrations. The tool becomes a hub for identity, ERP, finance, BI and messaging. Each connector is another dependency to replace on exit.
• Pricing. Per-seat licenses grow with headcount, not with value. Bundles add modules nobody asked for, and renewal terms often leave too little notice to plan a move.
• Skills and habits. Users, admins and reports are tuned to one interface. Retraining is a real cost that rarely appears in the original business case.

What are the signs that a company is locked in?

A quick self-check helps decide whether lock-in is a theoretical risk or an active cost. Each “yes” marks a dependency worth pricing before the next renewal.

• The license bill grows every year, while most users need only a small part of the product.
• Nobody can say how long a full migration would take or what it would cost.
• A complete export, with attachments, history and relations, has never been tested.
• Key business rules exist only as automations inside the tool.
• Reports and dashboards depend on the vendor’s own analytics module.
• The contract renews automatically, with a notice period shorter than a realistic migration.
• Feature requests wait on the vendor’s roadmap, and workarounds pile up in spreadsheets.
• Data residency or access rules depend on the vendor’s hosting choices.

What is data portability, and what rights do companies have?

Data portability is the ability to take data out of one system in a usable format and move it to another without losing meaning or history. In the EU, two regulations now support it, and they cover different data.

GDPR Article 20: portability for individuals

Article 20 of the GDPR gives individuals the right to receive the personal data they provided “in a structured, commonly used and machine-readable format” and to have it transmitted to another controller where technically feasible. The right belongs to people, not companies. It helps when employees or customers ask for their own data, but it does not oblige a SaaS provider to hand a business its full dataset.

EU Data Act: switching rights for business customers

The Data Act (Regulation (EU) 2023/2854) closes that gap for business customers. Its switching rules have applied since 12 September 2025 to data processing services offered in the EU, SaaS included. According to Cooley’s overview and DLA Piper’s analysis:

• a provider cannot require more than two months’ notice to start switching;
• exportable data and digital assets should move within a transition period of up to 30 days, extendable only where it is technically unfeasible;
• exports must use structured, commonly used, machine-readable formats, supported by open interfaces;
• switching and data egress charges are being phased out and are removed from 12 January 2027.

How to avoid vendor lock-in with current tools

Avoiding vendor lock-in does not mean avoiding SaaS. It means keeping the cost of leaving known and low, so the decision to stay is a choice and not a trap.

Data and business logic

• Test the export. Run a full export once a year and restore it somewhere else. Check attachments, history, relations and user permissions, not only the main tables.
• Keep a company-owned copy of the data. Replicate core records into a company-owned data store or warehouse on a schedule. Reports built on that copy keep working whatever happens to the tool.
• Document business logic outside the product. Fields, statuses, approval rules and automations belong in a short spec that both people and AI coding agents can read.

Integrations and contracts

• Integrate through a company-controlled layer. Route data through APIs, events and governed connectors that the company owns, so replacing one system does not break ten others. Azati builds such layers as part of its AI integration services.
• Negotiate exit terms. Ask for export formats, assistance on exit, data deletion confirmation and a notice period that matches a realistic migration. In the EU, the Data Act already caps the notice at two months.
• Review the stack regularly. Usage, cost per active user and overlap between tools change every year. A yearly review shows which subscriptions still earn their price.

How to get out of vendor lock-in

Getting out of vendor lock-in is a project with a clear order of steps. Skipping the early ones is the most common reason migrations run over time.

1. Inventory dependencies. List the data, workflows, integrations, users and reports tied to the tool, and who owns each.
2. Calculate both sides. Compare the three-year cost of staying with the cost of leaving: build or buy, migration, parallel run, training and support.
3. Choose the target. Another product, a hybrid with a custom layer on a trusted system of record, or software the company owns.
4. Prepare the data. Map fields, clean duplicates, agree on one source of truth per entity and classify personal data.
5. Run in parallel. Keep both systems live, reconcile results and move users in stages.
6. Decommission. End the subscription only after the new system has replaced the old one in daily work, and confirm data deletion with the provider.

Owning the software and the data

When ownership pays off

The most complete answer to vendor lock-in is ownership: the company holds the code, the data model and the infrastructure decisions. Until recently, that was realistic mostly for core products. AI-accelerated development has changed the math for internal tools, such as CRM, HR workflows, approvals, helpdesks and operations portals, where licenses scale per seat and most users need only part of the product.

Ownership is not automatically cheaper or safer. Owned software needs an architecture, security updates, support and a named owner, and in-house tools built without guardrails create a new kind of dependency on code nobody can maintain. That is why the decision starts with numbers for each tool, not with a general preference for building.

How Azati helps companies exit SaaS

Azati helps companies replace SaaS with AI-built software they own. The work starts with a SaaS Cost & Build vs Buy Assessment: a three-year TCO comparison and a build, buy or hybrid recommendation for each tool. Azati then prepares AI-ready data and guardrails for in-house teams, or delivers the full cycle through custom software engineering, from data migration with a parallel run to SaaS decommissioning and managed operation.

Azati works with the same trade-off in its own operations. Its 380+ person team runs project tracking, time logging, department reporting and leave management on one company-owned platform, built on open-source Redmine with a custom plugin that Azati develops, upgrades and maintains itself. Azati is now moving CRM functionality from a third-party SaaS product into its own internal platform in the same way.

Proven Results

Azati built and maintains a custom Redmine plugin that runs project tracking, time logging, department reporting and leave management for its own 380+ person engineering team on one company-owned platform.

When internal teams already build with AI coding tools, Azati’s Vibe Coding Engineering service reviews and hardens that code, so owned software does not turn into a new source of risk. For the review side of that work, see The Hidden Cost of Vibe Coding Without Code Review.

Frequently asked questions