Every vendor relationship starts with a compelling pitch: best-in-class features, competitive pricing, seamless integrations, and a roadmap that looks exactly like what you need. What the pitch doesn't cover is what happens when you want to leave.
Vendor lock-in is the condition where switching costs — technical, financial, or operational — have grown so high that leaving becomes effectively impossible even when a better alternative exists. It's not always engineered intentionally. Sometimes it emerges naturally from years of deep integration, proprietary data formats, and processes built around a specific platform. But the outcome is the same: you're paying whatever your vendor charges, accepting whatever service they deliver, and hoping their roadmap still aligns with yours — because the alternative is a migration project that could cost hundreds of thousands of dollars and six months of engineering time.
For growing SaaS companies specifically, vendor lock-in is an existential risk that rarely shows up on the balance sheet until it's too late to be cheap to fix. Here's where it typically hides — and how to quantify it before it controls you.
Category 1: Cloud Provider Lock-In
The cloud provider relationship is the deepest technical dependency in most SaaS stacks. Compute, storage, networking, databases, queuing, CDN, ML inference — once you're running a full workload on AWS, GCP, or Azure, you're not "using infrastructure." You're using a platform that has quietly become load-bearing in dozens of places you didn't consciously choose.
Egress fees that make switching prohibitively expensive
Moving data into a cloud provider is free. Moving data out — to users, to another provider, to an on-premises backup, or to a competitor's infrastructure — is priced as a deterrent. AWS charges $0.09/GB for outbound data transfer to the internet; cross-region transfers add another $0.02–$0.08/GB on top. A SaaS company serving 50TB/month of user data is paying $4,500/month in egress alone — and a provider-to-provider migration would require moving that data twice, generating a one-time egress bill in the $30,000–$100,000 range before a single application is refactored. This isn't a hidden fee — it's in the pricing docs — but most teams don't model it until they're mid-negotiation with a new provider and realize the economics don't work.
Proprietary managed services with no portable equivalent
AWS Lambda, Google BigQuery, Azure Cosmos DB, AWS DynamoDB — every major cloud provider offers managed services that have no direct equivalent elsewhere. Once your application is built on DynamoDB's query model, migrating to PostgreSQL isn't a configuration change. It's a re-architecture. The same applies to serverless functions, managed message queues, proprietary ML services, and CDN configurations. Each managed service you adopt deepens the coupling. The switching cost isn't just the compute — it's the months of engineering to rebuild the same capabilities on a different provider's primitives. Gartner estimates that 60–70% of cloud migration cost is application refactoring labor, not infrastructure.
Support tier pricing that scales with dependency
Enterprise cloud support contracts at AWS, GCP, and Azure are priced as a percentage of monthly spend — typically 3–10%. A company spending $200,000/month on infrastructure that needs dedicated support is paying $6,000–$20,000/month for that relationship. As your usage grows, your support bill grows proportionally, but your negotiating leverage doesn't — because by the time you're spending $200K/month, the switching cost of leaving has already made any serious negotiation moot. The support tier is a mirror of your lock-in depth.
How deep is your cloud dependency?
The free StackScope Technology Health Assessment scores your cloud infrastructure setup — including provider dependency risk, managed service concentration, and egress exposure — in 3 minutes.
Take the Free AssessmentCategory 2: SaaS Tool Sprawl
The average 50-person SaaS company runs between 40 and 80 SaaS subscriptions. Most of those were adopted one at a time by different teams, with overlapping feature sets, no central inventory, and no data portability plan. When the time comes to consolidate — either to reduce costs or to migrate to a competing platform — the problem isn't the monthly fee. It's the data trapped inside each tool.
Data that lives inside tools with no export path
CRM history. Sales sequences. Support ticket threads. Customer success playbooks built inside platform-specific tools. Product analytics dashboards. Five years of Slack conversation history. Most SaaS tools will export your data — eventually, in some format — but the export is rarely clean, rarely complete, and never maps cleanly to a competitor's import format. When HubSpot customers migrate to Salesforce (or vice versa), the technical migration is straightforward. The data quality work — reassigning ownership, mapping custom fields, reconstructing pipeline history — takes weeks. For a company with 5,000 contacts and 3 years of interaction history, this is a $50,000–$150,000 professional services engagement before you've signed the new contract.
Workflow automation that ties platforms together
The real switching cost of SaaS tools is often not the tool itself — it's the automation layer built on top of it. Zapier workflows. Make scenarios. Native integrations. Custom webhooks. A company that's spent 18 months building operational automations connecting their CRM, support desk, billing platform, and product database has created a dependency graph that can't be migrated by switching any one tool. Every tool change breaks the adjacent automations. This is why SaaS adoption without an integration architecture tends to compound into debt: the longer you run it, the more expensive every future change becomes.
Category 3: Database Lock-In
Database vendor lock-in is the most technically severe form — and the most common one that engineering teams don't fully price until they're in the middle of a migration they thought would take two months and is now in month eight.
Proprietary query dialects and extensions
Standard SQL exists in theory. In practice, every major database engine has extensions, stored procedure syntax, window function behavior, JSON handling, and replication models that deviate from the standard enough to matter. Oracle PL/SQL procedures don't port to PostgreSQL without rewriting. Microsoft T-SQL syntax doesn't run on MySQL. Applications that rely on database-specific functions — UUID generation, full-text search, geospatial queries, JSONB operators — require code-level changes at every call site when the database changes. For a mature application with hundreds of queries, this is months of work. For an application with stored procedures scattered across the codebase, it can be a complete rewrite of the data layer.
Proprietary data formats that don't export cleanly
MongoDB, Cassandra, DynamoDB, and other NoSQL databases store data in formats that have no direct relational equivalent. A document store schema that made sense when you were a 10-person startup with flexible requirements becomes a migration nightmare when you need to move to a relational database for compliance, analytics, or engineering sanity. The data itself may be exportable — most platforms provide export tooling — but transforming it into a new schema while maintaining referential integrity, handling denormalized edge cases, and keeping production live during the migration is a significant engineering project. Teams regularly underestimate this by a factor of three to five.
Category 4: API Dependency Risk
SaaS products built on third-party APIs are exposed to a risk category that's often invisible until it becomes critical: the vendor controls the interface, the pricing, and the availability — and can change any of them without notice.
API pricing changes that hit revenue directly
In 2023, Twitter increased API pricing by 100x overnight — from $100/month for basic access to $42,000/month for enterprise tier. Companies that had built products on Twitter's API had hours to decide whether to pay or shut down that feature. Reddit followed with similar pricing changes shortly after, breaking hundreds of third-party apps. These weren't edge cases — they're the natural endpoint of building a business dependency on a platform you don't control. For SaaS companies that have built core product features on a single third-party API (mapping, payments, communication, identity), a pricing change or terms-of-service update can represent an immediate 20–40% increase in COGS with no technical alternative in place.
Deprecation and version lock
Every API has a deprecation cycle. When Stripe, Twilio, Plaid, or any major API vendor deprecates a version, companies using the old API face a forced migration with a hard deadline. The migration is rarely just an API version bump — it often involves new authentication models, changed data schemas, updated webhook payloads, and retesting entire integration surfaces. For companies that have delayed upgrading across multiple versions, the catch-up migration can take months. The per-engineering-hour cost is typically $150–$250 fully loaded, and a major API migration across a mature codebase can easily consume 400–800 engineering hours. That's $60,000–$200,000 in remediation work for a problem that existed only because of accumulated technical debt around a single vendor integration.
Find out where your vendor dependencies are concentrated
The StackScope Technology Health Assessment identifies vendor concentration risk across your cloud, SaaS, and API stack — and scores your exposure relative to companies your size. Free, 3 minutes.
Get Your Vendor Risk ScoreHow to Measure Your Lock-In Exposure
Vendor lock-in risk isn't binary — it's a spectrum, and the exposure is measurable. Before you can manage it, you need to know what you're dealing with.
Switching cost audit. For each critical vendor, estimate the cost to replace them: migration labor in engineering hours, data transfer costs, downtime risk, retraining overhead, and productivity loss during transition. If you can't name a number within a range, you haven't thought about it seriously enough. Most teams are surprised by how high the realistic figure is when they go through it methodically.
Vendor concentration score. What percentage of your infrastructure runs on your primary cloud provider? What percentage of your customer-facing operations depend on a single payments vendor, a single communication API, a single identity provider? Single-vendor concentration above 70% in any critical category is a material business risk — not because failure is likely, but because it eliminates your negotiating leverage and your contingency options simultaneously.
Exit clause review. Read your contracts for data portability guarantees, export tooling commitments, migration support obligations, and termination notice periods. Enterprise SaaS contracts often have 90-day notice requirements — if you're mid-fundraise and your vendor changes pricing, you may not be able to act quickly enough. The contracts you signed when you were small often don't have the protections you need now.
Proprietary feature inventory. List every feature of your product that relies on a vendor-specific capability — a database extension, a managed service, a proprietary API endpoint — with no open or portable equivalent. These are your highest-risk dependencies. Each one is a refactoring project that will be forced upon you at some point; the question is whether you do it proactively or reactively.
What to Do About It
The goal isn't to eliminate vendor dependencies — that's neither practical nor desirable. It's to understand your exposure and make deliberate decisions about where concentration is acceptable and where it isn't.
Portable data architecture first. Regardless of which vendor you use, your data should be exportable in a documented, open format on a scheduled basis. Nightly exports to object storage you control. ETL pipelines that maintain a canonical data model independent of any vendor's schema. If your data lives exclusively inside a vendor's system with no independent copy, you're already locked in — the only question is whether you realize it yet.
Abstraction layers for critical vendor integrations. When a vendor integration touches core product functionality, wrap it in an interface that's not vendor-specific. A payment abstraction layer that could swap Stripe for Braintree without changing calling code. A notification service that abstracts over SendGrid or Postmark. This costs engineering time upfront and pays for itself the first time a vendor changes pricing or terms in a way that requires you to act quickly.
Multi-vendor for critical categories. For payments, identity, and communication — the three categories where a single-point failure creates immediate revenue or security impact — maintaining a secondary vendor relationship, even at minimal volume, keeps the migration path warm. It also gives you leverage in contract negotiations that you don't have when you're 100% committed.
Vendor lock-in is one of the most expensive infrastructure risks that doesn't appear on a risk register until it's already expensive. The companies that manage it well treat it like technical debt: quantify it regularly, pay it down deliberately, and never let it accumulate to the point where the bill is too large to pay in a single migration cycle.
If you want a structured read on where your technology stack's vendor exposure sits today, our Technology Health Assessment covers vendor concentration and infrastructure risk as scored categories. For companies already facing a forced migration or a contract renewal negotiation, a StackScope consultation includes a full vendor dependency audit with switching cost modeling.