Advanced Business Tech #vendor-lock-in #cloud-architecture #due-diligence #M&A

Vendor Lock-In Assessment

5 exercises — master vendor lock-in vocabulary for TDD: lock-in types (data portability, API lock-in, skill lock-in), cloud lock-in assessment (cloud-agnostic vs multi-cloud, proprietary service mapping), proprietary dependency risk (licence risk, vendor viability, concentration risk), lock-in risk register language (RAG, exit clause, source code escrow), and mitigation strategy vocabulary (abstraction layer, adapter pattern, off-ramp).

0 / 5 completed

Vendor lock-in quick reference

Lock-in types: Data portability (can't export data), API lock-in (proprietary APIs, no standard alternative), skill lock-in (team skills tied to one vendor), proprietary format lock-in.
Cloud lock-in test: Cloud-agnostic = Kubernetes + standard DBs = portable. Deep AWS-proprietary (DynamoDB, Step Functions, Cognito) = high migration cost. Multi-cloud = runs on 2+ clouds simultaneously (costly but portable).
Proprietary dependency red flags: Vendor recently acquired by competitor, no multi-year contract, no data export API, startup vendor with unknown runway.
Risk register rating: Low (migration <5% of deal value, stable vendor), Medium (5–15%, manageable), High (>15%, condition precedent or price adjustment).
Mitigation vocabulary: Abstraction layer (adapter pattern) = cheapest and most effective. Exit clause = contractual. Source escrow = vendor insolvency protection. Data portability sprint = eliminates data lock-in.

1 / 5

During TDD preparation, the lead assessor briefs the investment team: "One question I always ask in a vendor lock-in assessment is: 'If the CTO wanted to move this entire platform to a different cloud provider in 12 months, what would prevent that?' The answer to that question tells you everything about the real lock-in exposure."

What is vendor lock-in, what are its main types, and why does it constitute a business risk in an investment context?

The phrase "if this vendor disappears tomorrow" is the most clarifying framing for a lock-in assessment. It forces a concrete, honest answer: "Actually, we'd lose access to all our data" or "We'd have to rewrite 40% of the application." That's a real risk, quantifiable in time and cost.

Vendor lock-in types with TDD examples:

Lock-in type	Example	Migration cost signal
Data portability	Customer data in Salesforce with no export automation; proprietary data mart	Data migration complexity; potential data loss risk
API lock-in	Deep AWS proprietary service usage (Cognito, SQS patterns, Lambda layers); GCP-specific ML APIs	Full cloud migration: 6–24 months, $200K–$1M+
Skill lock-in	All engineers trained only in Salesforce Apex; proprietary low-code platform	Rehiring or retraining cost; talent market risk
Proprietary format	Document storage in vendor-proprietary format with no open export	Data conversion cost; potential permanent loss

Lock-in risk framing for investors:
• "The company has significant AWS API lock-in. Approximately 60% of their core infrastructure relies on AWS-proprietary services. A full migration to a competing cloud would take an estimated 12–18 months and cost $400K–$600K in engineering time. This is not an immediate risk — AWS is financially stable — but it eliminates all pricing leverage with AWS and creates concentration exposure."

Key vocabulary:
• Vendor lock-in — a state of dependency on a specific vendor that makes migrating to an alternative prohibitively costly or time-consuming
• Data portability — the ability to export, transfer, and reuse data across different systems and vendors; low portability = high lock-in
• API lock-in — dependency on proprietary vendor APIs with no standard alternative; switching vendors requires rewriting integrations
• Vendor concentration risk — the degree of business-critical dependency on a single vendor; high concentration = reduced negotiating leverage and single-vendor failure exposure

2 / 5

The TDD team is assessing a SaaS company's cloud infrastructure. The infrastructure engineer explains: "We're all-in on AWS. We use RDS, ECS, SQS, Cognito, Step Functions, and Lambda. Everything is Terraform-managed but all the Terraform providers are AWS-specific."

The TDD assessor responds: "That's a deep AWS footprint. Let me walk you through how I'd characterise the lock-in exposure and what questions we need to answer to rate it."

How do you assess and communicate cloud vendor lock-in in a TDD engagement?

The key insight is the distinction between deep AWS-proprietary services (hard to migrate, high-lock-in) vs cloud-agnostic services running on AWS (easy to migrate, low lock-in). A company can be 100% on AWS and have low lock-in if they use Kubernetes, PostgreSQL, and standard storage; or they can be 100% on AWS with extreme lock-in if they use Cognito, Step Functions, and DynamoDB.

Cloud lock-in assessment vocabulary:

Risk level	Indicators	TDD rating
Low	Kubernetes, standard PostgreSQL/MySQL, S3-compatible storage, open APIs. Migration: weeks, <$50K	Green — cloud-agnostic design; renewal leverage maintained
Moderate	Mix of proprietary and cloud-agnostic; CoGnito or SQS. Migration: 3–6 months, $100–300K	Amber — manageable; note in risk register
High	DynamoDB, Step Functions, Lambda integrations. Migration: 12+ months, $500K+	Amber-Red — pricing leverage concern; long-term strategic risk

Cloud lock-in assessment phrases:
• "The company is cloud-agnostic in practice — all services run on Kubernetes with Helm charts designed to be provider-portable. AWS is the current runtime but the architecture is designed for migration if required."
• "The company has deep AWS proprietary lock-in: DynamoDB, Cognito, and Step Functions are core to the product architecture. A migration to another cloud would require rewriting these integration layers — estimated 12 months and $450K."

Key vocabulary:
• Cloud-agnostic architecture — an infrastructure design using open, portable technologies (Kubernetes, standard open-source databases) that can run on any major cloud provider with limited migration effort
• Multi-cloud — actively running workloads on two or more cloud providers simultaneously; provides extreme resilience and zero lock-in but significantly increases operational complexity and cost
• Vendor pricing leverage — the credible ability to threaten migration to a competing vendor at contract renewal; deep lock-in eliminates this leverage, typically resulting in above-market pricing over time

3 / 5

The TDD engineer discovers that one of the target company's core business functions depends on a third-party analytics platform with a proprietary API and no data export capability. She notes: "This vendor was acquired by a competitor 8 months ago. We need to assess licence risk, vendor viability, and what happens to the target company's product if this vendor changes its terms or discontinues the service."

How do you assess and communicate proprietary dependency risk in a TDD engagement?

The key risk signal here — a critical-path vendor recently acquired by a competitor — is one that many non-technical investors will miss. A competitor acquiring a key supplier is a classic strategic lock-in pressure tactic. In TDD, this becomes a specific, actionable finding.

Proprietary dependency risk assessment framework:

Risk dimension	Assessment question	Red flag
Licence risk	"Is there a multi-year contract with price caps, or month-to-month?"	No contract; month-to-month; no price protection clause
Vendor viability	"Is this vendor financially stable? Any signals of discontinuation?"	Recently acquired; early-stage startup; recent layoffs; deprecated roadmap
Concentration risk	"What % of business-critical functions depend on this single vendor?"	>50% of a core function in one vendor with no feasible alternative
Data exportability	"Can you export all your data from this vendor? In what format?"	No export API; proprietary-only format; no documented exit path

Proprietary dependency risk language in TDD reports:
• "The company's core analytics capability is entirely dependent on Vendor X, which was acquired by a direct competitor 8 months ago. There is no multi-year contract, data export is not available via API, and the replacement timeline if service is discontinued is estimated at 6–9 months of internal build. This is rated Amber-Red pending review of the new owner's strategic intentions."

Key vocabulary:
• Licence risk — the risk that a vendor changes its licence terms, pricing, or access policies at renewal; elevated when there is no long-term contract with price caps
• Vendor viability — the probability that a vendor continues to exist and maintain the service as sold; assessed through revenue signals, acquisition context, and roadmap visibility
• Vendor concentration risk — the proportion of business-critical functionality dependent on a single third-party supplier; high concentration = fragile, with no fallback if vendor terms change

4 / 5

Having completed the vendor dependency mapping, the TDD assessor needs to formalise findings into the risk register. She explains to the investment team: "For vendor lock-in, I use a three-part rating: the severity of the lock-in, the current mitigation (if any), and the recommended mitigation with cost. Some lock-in is unavoidable and acceptable — the question is whether there's a credible plan."

How is vendor lock-in rated and communicated in a formal TDD risk register?

The key phrase in lock-in risk rating is "migration cost as a percentage of deal value." This immediately contextualises the risk: a $200K migration cost is immaterial on a $20M deal but meaningful on a $2M deal. Investors think in percentages and multiples, not absolute dollar amounts.

Vendor lock-in risk register vocabulary:

Rating	Migration cost signal	Mitigation options	Deal impact
Low / Green	<5% of deal; weeks or minor refactor	None required; note and monitor	No deal impact
Medium / Amber	5–15% of deal; 3–9 months	Abstraction layer; multi-year contract with caps; develop open-source fallback	Risk register entry; integration plan item
High / Red	>15% of deal; 12+ months; functionally impossible	Source escrow; exit clause; full migration plan pre-close	Price adjustment or condition precedent

Lock-in risk register entry language:
• "Risk ID: LOCK-003. Description: Core analytics pipeline is entirely dependent on Vendor X API with no alternative. Vendor acquired by a competitor 8 months ago; no multi-year contract; no data export capability. Likelihood: High (competitor ownership incentivises pricing pressure). Impact: High (analytics is core product feature, no existing fallback). Residual risk: High. Recommended action: negotiate exit clause in renewal; initiate internal analytics rebuild programme in Year 1; estimated cost $180K over 6 months."

Key vocabulary:
• Exit clause — a contractual provision that allows termination under specific defined conditions (vendor insolvency, acquisition by competitor, failure to meet SLA); reduces lock-in risk by creating a legal off-ramp
• Source code escrow — an arrangement where the source code of a critical third-party product is held by a trusted third party and released to the purchaser if the vendor becomes insolvent
• Open-source alternative — an open-source product that can functionally replace a proprietary vendor dependency; the existence of a credible open-source alternative significantly reduces lock-in risk rating

5 / 5

The TDD lead is drafting the vendor lock-in mitigation strategy section. The investment team wants to know: "You've told us about the risk. Now tell us how to manage it — not just 'don't use that vendor' but a real architectural strategy that can be implemented without stopping product development."

What architectural vocabulary and strategies are used to present vendor lock-in mitigation to an investment committee?

The abstraction layer / adapter pattern recommendation is the "credible partial mitigation" that investment committees love: it's inexpensive, it doesn't stop product development, and it dramatically reduces the cost of a future migration. It converts an existential risk into a manageable risk for a known upfront investment.

Lock-in mitigation strategies in TDD recommendations:

Strategy	What it does	Cost / complexity	Risk reduction
Abstraction layer	Wraps vendor API in internal interface; only implementation changes on migration	Low — 1–3 sprints; $20–60K	High — migration cost drops 60–80%
Dual-sourcing	Primary + fallback vendor configured; eliminates operational lock-in	Medium — ongoing operational overhead	Eliminates outage risk; not pricing risk
Data portability sprint	Automated export to standard format; eliminates data portability lock-in	Low — 1–2 sprints; $15–30K	Eliminates data portability risk completely
OS alternative eval	Document open-source replacement; pre-validate feasibility	Very low — design/research only	Reduces emergency migration timeline significantly

Mitigation recommendation language for investment presentations:
• "We recommend implementing an abstraction layer over the analytics vendor integration during the first integration sprint. The estimated cost is $35,000. This reduces the migration risk from 'existential — 12 months to replace' to 'manageable — 3 months to replace.' We view this as a mandatory Year 1 integration activity."
• "We recommend data portability tooling for the third-party CRM as a condition precedent. This is a 2-week development effort. Without it, a future vendor change would require manual data migration with risk of loss."

Key vocabulary:
• Abstraction layer (adapter pattern) — a thin internal interface wrapping a vendor API; the vendor-specific implementation lives behind the interface; enables vendor replacement by changing only the implementation layer, not all call sites throughout the codebase
• Anti-corruption layer — a domain-driven design pattern that translates between the domain model and an external vendor's data model; prevents vendor-specific data structures from leaking into the core business logic
• Off-ramp — an architectural pattern or contractual provision that provides a practical, documented path to exit a vendor relationship without catastrophic cost; the goal of all lock-in mitigation strategies