SaaS lock-in: five signs you're already paying it

Quick answer: SaaS lock-in shows up as: workflows that don’t export, integrations that have to be rebuilt to leave, historical data that exports without referential integrity, automations stored as platform-specific rules, and a team trained around platform-specific UX. By the time you notice it, the cost of leaving usually exceeds the cost of staying — even if the platform has gotten worse.

Vendor lock-in is one of those phrases that sounds dramatic and gets dismissed as overblown. In practice, it’s rarely dramatic. It’s a slow accumulation of small commitments, each of which seemed reasonable at the time, that collectively make moving prohibitively expensive.

Here’s what it actually looks like.

Wikipedia’s article on vendor lock-in covers the same dynamics across software, cloud, and SaaS — the structural patterns repeat.

1. Workflows that don’t export

The single most expensive form of lock-in is the workflows you’ve built inside the platform.

Examples we see regularly:

• A 14-stage HubSpot or Salesforce sales pipeline with custom stage entry / exit criteria
• A GoHighLevel funnel with conditional logic, A/B splits, and SMS / email branching across 50+ steps
• An ActiveCampaign automation map covering customer onboarding from sign-up to year-three retention
• Zapier or Make scenarios connecting eight tools with custom transformations between each

What these have in common: they’re not data, they’re logic. Data exports cleanly. Logic doesn’t. There’s no “export workflow” button in any major SaaS platform that produces something portable to a different platform — the closest you’ll get is a JSON dump nobody else can read.

If you tried to leave the platform tomorrow, every one of these workflows would have to be rebuilt from scratch on the new system, by people who understand both platforms well enough to translate between them. That’s a project, not a migration.

2. Integrations you’d have to rebuild

The second-largest form of lock-in is the integration layer.

A platform that’s been operational for two or more years typically has:

• Native integrations to 5–15 other tools, configured with specific field mappings
• Webhook-driven API integrations that other systems depend on
• A handful of low-code automation flows wiring it to platforms it doesn’t natively connect to
• Custom code (somewhere) that consumes the platform’s API to power a dashboard, a report, or an internal tool

Each of those is a thread that has to be unpicked and rewoven on the new platform. None of them is hard individually. Collectively they represent weeks-to-months of engineering work, and that work is pure overhead — you spend it just to get back to where you were.

3. Historical data that exports without referential integrity

Most platforms will let you export your data. What they won’t do is preserve the relationships between records.

The pattern that bites: you export contacts as a CSV, deals as a CSV, activities as a CSV. The new platform imports each one. Now the contact-to-deal relationship is gone, the activity history is detached from the contact, and the lifecycle stage progression is a single field rather than a time-stamped history.

You can rebuild the relationships, but it requires either:

• A custom migration script written by someone who understands both data models
• Or accepting that historical data on the new platform is effectively a read-only archive, with everything from the cutover date forward being the “real” history

Both options are reasonable, neither is free, and both are a meaningful lock-in cost.

4. Automations stored as platform-specific rules

Look at the platform’s “automations” or “workflows” section. Count how many rules exist. Now ask: where is the documentation that explains why each rule exists?

In most operations we audit, the answer is “it’s in the head of the operations lead.” Some rules made sense once and are now redundant. Some have subtle dependencies on other rules that aren’t obvious from reading them. Some were set up by a former staff member nobody can ask about.

Migrating that off-platform requires either:

• Reverse-engineering each rule’s purpose and recreating it on the new system
• Or writing the rules off as “technical debt” and rebuilding the operation from scratch

The second is sometimes the right call. It’s also the most expensive lock-in cost in the list.

5. Team trained around platform-specific UX

The most underrated form of lock-in is human.

A team that’s used HubSpot for three years has internalised HubSpot’s UX patterns. Where the navigation lives. How filters work. The keyboard shortcuts. The mental model for what “contacts”, “deals”, and “tickets” mean specifically. Switching them to a different CRM — even an objectively better one — means several months of reduced productivity while everyone retrains.

For a 20-person sales team, that’s a real cost. Conservatively: 10–15% productivity loss for two months across 20 people = roughly 60–90 person-days. At loaded cost, $30,000–$70,000.

This isn’t an argument against ever switching platforms. It’s an argument for not switching unless the new platform is meaningfully better and the migration is genuinely necessary.

What lock-in actually costs

A back-of-envelope estimate for a 50-staff business considering migrating off a meaningful SaaS platform:

• Workflow rebuild: 4–12 weeks of operations + engineering work = $30,000–$120,000
• Integration rebuild: 2–8 weeks of engineering work = $20,000–$80,000
• Data migration: 1–4 weeks for a custom-scripted migration = $10,000–$40,000
• Team retraining: 60–90 person-days lost productivity = $30,000–$70,000
• New platform onboarding fees + first-year overlap: $5,000–$30,000

Total switching cost: roughly $95,000 to $340,000 for a business at that scale, before counting the cost of the new platform itself.

Compare that to staying on the existing platform — even one that’s gotten worse, more expensive, or less aligned with your needs — and you can see why most businesses simply don’t leave.

How to reduce future lock-in

You can’t eliminate lock-in. You can manage it deliberately.

• Run integrations through code you own, not through low-code platforms. A custom integration layer is portable; a Zapier scenario is not.
• Keep your source of truth outside the platform where possible. Customer data in a database you own, with the SaaS platform as a consumer of that data, gives you optionality the other way around does not.
• Document workflows externally. Even a simple Notion page describing what each automation does and why means the next operator (or migration) doesn’t start from a blank page.
• Avoid platform-specific page builders / form tools where alternatives exist. Pages and forms migrate poorly between platforms.
• Default to standard data models rather than heavily customising the platform’s schema. The closer your usage is to the platform’s defaults, the more portable your data is.

These aren’t about “preparing to leave the platform.” They’re about not making the platform more sticky than it needs to be — which gives you genuine optionality the day the platform’s economics, features, or ownership change in a direction you don’t like.

Common questions

What is SaaS vendor lock-in? The structural cost of leaving a SaaS platform: workflows that don’t export, integrations that have to be rebuilt, data that exports without referential integrity, platform-specific automation rules, and team retraining time. It compounds every year you’re on the platform.

Is SaaS lock-in really a problem? For most businesses under 20 staff, no — the migration cost is small enough that switching platforms is a mild inconvenience. For businesses at 50+ staff with meaningful platform usage, lock-in is real and expensive. The single cheapest moment to think about it is before you commit, not after.

How do I reduce my dependence on a SaaS platform? Run integrations through portable code, keep your source-of-truth data outside the platform where possible, document workflows externally, avoid platform-specific builders, and resist heavily customising the data model. Practically, the hidden costs of SaaS at scale and lock-in problems share the same fix.

Can I get all my data out of HubSpot / Salesforce / GoHighLevel? Mostly yes — the records, contacts, deals, and basic relationships export. What you can’t cleanly export is the logic layer: workflow definitions, automation rules, page builder configurations, sales pipeline stage criteria. Those have to be rebuilt on the new platform.

Should I avoid SaaS to avoid lock-in? No — SaaS is genuinely the right answer most of the time, especially at small scale. The right move is using SaaS deliberately with awareness of where the lock-in points are, rather than building structurally-sticky setups by accident. The build-vs-buy framework goes deeper.

If you’re uncertain how locked-in you already are, start a project for an honest audit. Sometimes the answer is “less than you think; here’s how to keep it that way.” Sometimes it’s “more than you think; here’s the path to optionality.”