Vendor Lock-In Audit: How to Evaluate Your SaaS Stack's Exit Costs Before It's Too Late

Every SaaS tool in your stack creates switching costs. Some are trivial: swap one email marketing platform for another in an afternoon. Others are existential. Your entire workflow engine, data model, and team knowledge are fused to a platform you can't leave without a six-month migration. The difference between these two situations is vendor lock-in risk, and most teams don't think about it until they're already trapped.

We see this from the other side. Companies come to us when they've hit the ceiling on a platform and need to move. The migration is always more expensive than they expected, not because the new system is complex, but because the old one has tentacles they didn't know about. Data in proprietary formats. Business logic embedded in a visual builder with no export. Integrations that only work through the vendor's ecosystem.

This doesn't mean you should avoid SaaS. That's not realistic and it's not smart. It means you should know what you're signing up for. This is a framework for auditing your SaaS stack's exit costs before they become a crisis.

The vendor lock-in spectrum: not all dependencies are equal

Lock-in exists on a spectrum. At one end, you have tools that use standard protocols, export your data in open formats, and integrate via documented APIs. At the other end, you have platforms where your data, logic, and workflows are encoded in proprietary structures that only exist inside that vendor's walls.

The mistake most people make is treating all vendor dependency the same, either paranoid about everything or oblivious to everything. Neither works. Some lock-in is perfectly fine. Some will eventually become an existential threat to your ability to evolve.

Low-risk lock-in (standard interfaces, easy exit):

Cloud hosting on AWS, GCP, or Azure with standard services (compute, storage, databases). Yes, each has proprietary services, but if you're running containers and Postgres, you can move.
Email delivery services (SendGrid, Postmark, Resend). They all speak SMTP. Your templates are HTML. Switching takes a day.
Payment processing (Stripe, Braintree). The Stripe API is great, but your customer data, subscription models, and payment methods all have standard migration paths.
Monitoring and logging (Datadog, Grafana, New Relic). You're sending metrics and logs. The ingestion format changes; the data generation doesn't.

High-risk lock-in (proprietary formats, painful exit):

Workflow and automation engines (Monday.com automations, Salesforce flows, ServiceNow workflows). Your business logic lives inside their visual builder with no standard export. You can't take the "code" with you because there is no code. It's a proprietary graph of nodes and conditions.
No-code/low-code app builders (Bubble, Retool with heavy custom logic). The app only exists on their platform. There's no "download as source code" button.
CRMs with deep customization (Salesforce with 200 custom objects, HubSpot with dozens of custom workflows). The data is technically exportable, but the relationships, automation rules, and computed properties are not.
Proprietary data formats and analytics (tools that store your data in formats only readable by their platform).

The pattern: tools that store and transform your data using open, standard formats are low-risk. Tools that encode your business logic or data structures in proprietary formats are high-risk. The more of your "how we work" that lives exclusively inside a vendor's system, the higher the exit cost.

The exit cost scorecard

For every critical tool in your stack, score these five dimensions from 1 (low risk) to 5 (high risk):

1. Data portability. Can you export all your data in a standard, machine-readable format? CSV and JSON are table stakes. If the export is a PDF report or a proprietary backup file you can only restore into the same platform, that's a 5.

2. Logic portability. How much of your business logic lives inside the tool? A CRM that stores contact records is a 1. A CRM with 50 custom workflow automations, computed fields, and lead scoring rules is a 4-5. That logic has to be rebuilt from scratch in any new system, and it's rarely documented anywhere except in the tool itself.

3. Integration depth. How many other tools in your stack depend on this one? A standalone tool with two API connections is easy to swap. A tool that sits at the center of eight integrations, where every other system reads from it or writes to it, is a load-bearing wall. Removing it means rearchitecting the connections, not just the tool.

4. Team knowledge dependency. How much institutional knowledge is encoded in the way your team uses this tool? Custom naming conventions, workaround processes, undocumented configurations. If the "how" of your operations lives in your team's heads specific to this platform, the switching cost includes retraining, which is real time and real money.

5. Contract and financial exposure. Annual contracts with cancellation penalties. Data held hostage behind enterprise-tier export features. Migration tools that only exist if you pay for a premium plan. Some vendors make it intentionally expensive to leave. Score this based on how hard they make it to walk away, not just how much you're paying.

Add up the score. 5-10 is manageable. 11-17 means you should have a documented exit plan. 18-25 means you're in a dependent relationship with this vendor, and you should be actively reducing that dependency.

Where lock-in is acceptable (and where it's dangerous)

Not every high-dependency relationship is a problem. The question is whether the lock-in is in a layer where you can tolerate it.

Lock-in is usually fine at the infrastructure layer. If you're running on AWS and using standard services (EC2, RDS, S3), your switching cost is real but bounded. Containers are containers. Postgres is Postgres. S3-compatible storage exists everywhere. The infrastructure layer is well-standardized, and migrations, while annoying, are well-understood projects with clear scope.

Lock-in is usually fine for commodity services. Email, SMS, payment processing, file storage, CDN. These are interchangeable because they do one thing through standard protocols. The switching cost is measured in hours, not months.

Lock-in gets dangerous at the business logic layer. This is where we see companies get stuck. They started with a no-code automation tool to handle their client onboarding workflow. Three years later, 40 workflows encode every operational process in the company. The tool's pricing doubles. Or the tool doesn't support a use case they now need. Or the vendor gets acquired and the product roadmap changes. And they can't leave because leaving means rebuilding every workflow from scratch, including the ones nobody remembers building.

This is the same pattern we see with Zapier at scale. The tool is great until your business logic complexity exceeds what the platform can express, and by then, your switching cost is enormous.

Lock-in is most dangerous at the data model layer. If a vendor owns your canonical data model, the source of truth for how your business entities relate to each other, you have the deepest form of dependency. Migrating away means not just moving data but re-creating the relationships, hierarchies, and computed properties that your entire operation depends on. This is why CRM migrations from deeply customized Salesforce instances routinely take 6-12 months and cost six figures.

How to architect for optionality

You don't need to avoid SaaS tools. You need to keep your options open. In practice:

Own your data model. If possible, make your own database the source of truth. Sync data to SaaS tools, don't let SaaS tools be the canonical store. When your Postgres database is the truth and HubSpot is a synced copy, switching CRMs is a migration project. When HubSpot is the truth, switching CRMs is a data archaeology project.

Wrap vendor-specific logic in your own abstractions. If you're calling a vendor API from ten places in your codebase, you're locked in at ten integration points. If you're calling your own service that talks to the vendor, you're locked in at one. When you need to switch, you rewrite the adapter, not the ten call sites. This is the same pattern that makes incremental migrations possible.

Document your business logic outside the tool. Every workflow in your automation platform, every custom field calculation in your CRM, every scoring rule in your analytics tool. Write down what it does and why in a place you control. A shared doc, a wiki page, a README in your repo. When the migration comes, the most expensive part is figuring out what the old system actually did. Past-you doing this documentation work saves future-you weeks.

Choose tools with real APIs and standard export. Before you commit to a platform, test the exit path. Can you export your data in a standard format? Can you access everything via API? Are there documented migration guides from competitors? If the answer to all three is no, you're signing up for a roach motel — easy to check in, hard to check out.

Build critical workflows in code, not in vendor platforms. For your core operational workflows (the ones that handle money, customer data, or mission-critical processes), the safest move is to own the logic in code you control. Use SaaS tools as services your code calls, not as the runtime environment for your business logic. Your automation technical debt gets a lot more manageable when the logic lives in version-controlled code rather than scattered across vendor platforms.

Run the audit before you need it

The exercise takes about two hours and might save you six months.

List every SaaS tool your company depends on. Not just pays for, depends on. Include the free tools that would be painful to replace.
Score each one on the five-dimension exit cost scorecard. Be honest. If you're not sure about data export, try it. You'll learn a lot from attempting to export your own data.
Flag anything scoring 18+. These are your high-dependency vendors. For each one, answer: "If this vendor doubled their price tomorrow, or got acquired and shut down the product, what would we do?" If you don't have an answer, you need one.
Create a lightweight exit plan for your top 3-5 risks. Not a full migration plan. Just: where does the data go, where does the logic go, what's the rough timeline and cost. Update it yearly.

Most companies that do this audit discover one or two surprises: tools they assumed were easy to leave that are actually deeply embedded. Better to discover that during a two-hour exercise than during a crisis when the vendor changes terms or gets acquired.