# The Switching-Cost Score: Grading Vendor Lock-In Before You Build

*You can score a candidate vendor's lock-in on five named dimensions from public evidence and defend a low, medium, or high exit-cost verdict in a build decision.*

- Canonical URL: https://www.refolk.ai/guides/switching-cost-score-vendor-lock-in
- Pillar: Engineering and open source
- Format: Framework
- Published: 2026-09-17
- Last reviewed: 2026-09-17
- Reading time: 16 min

Before you build a load-bearing system on a vendor's platform, you owe the decision one honest number: how hard would it be to leave? This guide gives engineering managers, technical founders, and architects a repeatable rubric that turns public artifacts - API docs, export endpoints, standard conformance, egress schedules, and license terms - into one comparable exit-cost verdict per vendor. The aim is that two engineers grading the same vendor from the same evidence land on the same low, medium, or high.

Existing writing on lock-in is either mitigation advice for after you have signed or a checklist for the negotiation. This is neither. It isolates a single judgement - switching cost - and makes it gradable, defensible, and reproducible.

## What lock-in actually is, and what you can grade before signing

Lock-in is not vendor stickiness in the abstract. The hard definition worth adopting: lock-in exists when switching supplier stops being a procurement decision and starts requiring you to accept one of three things - losing important data or capability, paying significant exit costs, or rebuilding systems and processes from scratch. If you can swap suppliers with a purchase order, there is no lock-in to grade.

Five dimensions are gradable from public evidence before you sign. Each has an artifact that proves it, and each has a tell for when the artifact is lying.

| Dimension | What proves it | What it looks like when it lies |
| --- | --- | --- |
| Data export | Documented bulk export API or portability endpoint | Endpoint omits configs, permissions, or history |
| API uniqueness | Published standard interface vs proprietary calls | Standard "supported" over a subset only |
| Open-standard conformance | S3 API, OTLP, OpenAPI, Kubernetes | Marketing claim with no conformance test |
| Proprietary format risk | Exports land in CSV/JSON/XML vs closed binary | Open format, undocumented schema |
| Contract and egress terms | Published egress schedule, termination clauses | Free-exit waiver scoped to account closure only |

Practitioner frameworks converge on similar buckets. One AI-vendor rubric grades data portability, deployment flexibility, workflow portability, AI model dependency, and contract structure. The dimensions above are the version you can populate entirely from a vendor's own public documentation, which is what makes the score reproducible rather than a matter of taste.

> **Note:** Grade at adoption, not at renewal
>
> Lock-in that compounds with usage should be scored higher before you build. Value and switching cost rise together, so the cheapest moment to grade is the moment before the first instrumentation goes in.

## The five dimensions and how to score each 1 to 3

Score every dimension on a 1-to-3 scale where 1 is low exit cost and 3 is high. The scores are per-dimension, not a running total yet; combining and overrides come later.

**Data export (1-3).** A documented bulk export API that returns the full tenant, including configs and history, is a 1. A partial export, or one that requires a support ticket, is a 2. No documented bulk export is a 3 and, as you will see, an automatic high overall.

**API uniqueness (1-3).** A published, standard interface you could point at another vendor is a 1. A proprietary API with a documented spec is a 2. A proprietary black box holding core business logic is a 3.

**Open-standard conformance (1-3).** Conformance to a named standard - S3 API, OTLP, OpenAPI, Kubernetes - scores 1. Partial conformance is a 2. No standard interface is a 3. The Data Act itself now requires that interoperability between cloud services be defined through common technical standards, so absence of any named standard is a genuine signal, not a stylistic preference.

**Proprietary format risk (1-3).** Exports in CSV, JSON, or XML with a documented schema are a 1. An open container with an undocumented schema is a 2. A closed binary is a 3 and, like a missing export, forces a high overall.

**Contract and egress terms (1-3).** Zero or near-zero egress with clean termination is a 1. Tiered hyperscaler egress with standard notice is a 2. Opaque per-export fees or contract terms that make leaving commercially irrational are a 3.

OpenTelemetry deserves a special note because it is the load-bearing observability signal. The promise is concrete: instrument your code once using OpenTelemetry APIs and SDKs, export telemetry to any backend - Jaeger, Prometheus, commercial vendors, or your own - and switch backends without touching application code. Its adoption is not theoretical; the OpenTelemetry Python SDK alone shows 224 million downloads in the last month. A vendor that ingests OTLP is one you can leave without re-instrumenting, which is worth a full point.

## Reading egress schedules as an exit-cost signal

Egress is the one dimension with a published dollar figure, so read it precisely. First-tier per-GB egress rates are public and vary enormously. Because your exit volume is roughly fixed, the per-GB rate is a pure multiplier on the cost of leaving.

| Provider | Egress $/GB | 10 TB exit cost | Signal |
| --- | --- | --- | --- |
| AWS | 0.09 | $913 | Medium |
| Azure | 0.087 | $882 | Medium |
| GCP Premium | 0.12 | $1,137 | High |
| Cloudflare R2 | 0.00 | $0 | Low |
| Oracle (after 10 TB free) | 0.0085 | ~$0-85 | Low |

The spread is the story. Egress costs vary by up to 127x across providers, from $0.00/GB on Cloudflare R2 to $0.12/GB on GCP Premium Tier. Zero-egress storage such as R2, which charges $0.015 per GB-month to store and nothing to leave, is a low-cost signal on its own. Tiered hyperscaler egress is medium. Opaque or per-export fees are high.

**127x - Spread in first-tier egress rates across cloud providers**

From $0.00/GB on Cloudflare R2 to $0.12/GB on GCP Premium Tier, a pure multiplier on fixed exit volume.

Two regulatory facts reshape this dimension. First, the EU Data Act has applied since 12 September 2025 and removes switching and data-egress charges from 12 January 2027. Second, it caps the exit clock: the notice period a provider can require shall not exceed two months, followed by a mandatory maximum transitional period of 30 calendar days to complete the switch. AWS, Azure, and Google already waived egress fees for full account exits in 2024, and Google launched "Data Transfer Essentials" on 11 September 2025, one day before the switching provisions applied.

But read the scope. The fee ban covers switching egress only; operational egress remains billable. A vendor has every incentive to classify your exit traffic as ordinary usage. When the fee goes to zero, the load-bearing dimension shifts from egress to format and API - the proprietary interfaces, vendor-specific data formats, and identity binding that keep buyers locked in longer than any invoice.

## Estimating the migration effort you would actually eat

The exit-cost verdict has to account for the work of leaving, not just the invoice. Migration effort benchmarks exist, but they are vendor and consultancy estimates, not peer-reviewed figures, so treat them as directional bands rather than promises.

| Strategy | Typical duration | Nature of the work |
| --- | --- | --- |
| Rehost (lift-and-shift) | weeks | Move as-is, minimal change |
| First small workload | 1-2 months | Establish the pipeline |
| Replatform / medium | 2-6 months | Adapt to the target |
| Refactor, large system | 6-18 months | Break monoliths, rewrite bindings |

The refactor band is the one that matters for a load-bearing system: these efforts frequently span 6 to 18 months per large, business-critical system, particularly when breaking monoliths into microservices. Overruns are the norm, not the exception - 61% of enterprise migration projects exceed timelines by 40 to 100%. Notice the mismatch this creates against regulation: the Data Act caps your exit clock at two months plus 30 days, but the actual rebuild still runs 6 to 18 months. The right to leave arrives faster than any system can move.

#### Where the exit-cost estimate narrows

| Stage | Figure | Note |
| --- | --- | --- |
| Egress invoice | $0 to $1,137 | often the smallest cost |
| Format reformatting | weeks | if schema is undocumented, add months |
| API re-instrumentation | months | unless the vendor speaks a standard |
| Refactor of core logic | 6-18 months | the real switching cost |

*Most vendors clear the early stages; the refactor timeline is where a verdict is won or lost.*

This is why lock-in that compounds should be graded early. A 2026 survey found 81% of enterprise leaders concerned about AI vendor dependency, while only 6% could switch without material disruption. The mechanism is sunk cost: implementation effort creates sunk cost, which is a factor in how lock-in happens. AI-specific lock-in is worse than traditional SaaS lock-in because the value of the system increases with usage, making the switching cost grow over time.

> The fee was only the most visible lock-in. Proprietary APIs and vendor-specific formats keep you locked in longer than any invoice.

## Can you hire the people who execute the exit?

A low format-and-standard score assumes you can find engineers who know the open standards well enough to run a migration. That assumption is not evenly true across markets. In Refolk's index of professional profiles, the supply of open-standard skill is geographically lopsided.

| Query | Count | Derived ratio |
| --- | --- | --- |
| OpenTelemetry, United States | 1,687 | baseline |
| OpenTelemetry, Germany | 298 | 0.18x US (5.7x scarcer) |
| Terraform + "cloud migration", US | 454 | baseline |
| Kubernetes + "cloud migration", US | 411 | 0.91x Terraform |

**5.7x - How much scarcer OpenTelemetry talent is in Germany than the US**

In Refolk's index, 298 Germany profiles list it against 1,687 in the US - ironic given the Data Act is EU law.

The irony is exact: regulation creates the right to leave faster than the labor market supplies people to execute it. If your exit plan is "we'll just hire migrators," check whether those migrators exist where you operate before you count the open-standard dimension as a clean low. The US supply of migration-capable engineers is roughly balanced across tooling - 454 Terraform-plus-cloud-migration profiles against 411 for Kubernetes, a 0.91x ratio - so in that market the constraint is less about which skill and more about volume.

I ran this search: `Engineers in Germany who have moved production observability off a proprietary APM to OpenTelemetry.` - [see the full result list](https://www.refolk.ai/s/ndde9b7xpc).

*Returns named engineers who have run exactly the migration your low score assumes is cheap, so you can price the labor before you commit.*

Naming the people who have already done the migration turns an abstract "we could leave" into a staffed plan. This is the friction [Refolk](/) removes: you ask for the exit-executors in plain English and get them back, instead of guessing whether the talent exists.

## The scoring procedure, step by step

Run these eight steps in order. The whole assessment is about three engineer-days per vendor, split across an architect, an engineering manager, and a second grader. Sources disagree on order - some frameworks put contract review first, others put dependency mapping first - and either sequence works as long as both artifacts get graded.

#### Grading one vendor's switching cost

1. **Scope the dependency** - List every function that would break if the vendor changed pricing, terms, or availability, mapped to the business function it supports. Produce a written dependency inventory. (~1 day)
2. **Pull the export artifact** - Find the bulk export API or portability endpoint in public docs. Record the URL and the named output format. (~half day)
3. **Grade format portability** - Confirm exports land in CSV/JSON/XML versus a proprietary binary. Classify low, medium, or high. (~1 hour)
4. **Check open-standard conformance** - Test for S3 API, OTLP/OpenTelemetry, OpenAPI, and Kubernetes portability. Mark each present or absent with a doc link. (~half day)
5. **Read egress and contract terms** - Capture egress $/GB, notice period, termination and auto-renewal clauses. Estimate exit cost in dollars and the exit clock in days. (~1 day)
6. **Estimate migration effort** - Map the workload to a timeline band and name the strategy: rehost weeks, replatform months, refactor 6-18 months. (~half day)
7. **Score and combine** - Apply per-dimension 1-to-3 scores, then apply the override rules. Record a single low/medium/high verdict and the override check. (~1 hour)
8. **Run the second-grader check** - A different engineer grades the same vendor from the same artifacts. Confirm the verdicts match, or log and reconcile the disagreement. (~1 hour)

## Combining the scores and the overrides that force a high

Sum the five per-dimension scores for a raw signal, but do not let the sum be the verdict on its own. No published rubric dictates the weighting, which is where judgement enters. The guiding principle is a portfolio view, not a pure sum: lock-in is not the enemy; unmanaged lock-in is the enemy. The discipline is to price the exposure explicitly, accept it where the trade is good, and refuse it where the strategic cost outweighs the operational convenience.

Two override triggers force a high verdict regardless of the total. Any one of these caps the score.

> **Rule:** Two overrides that force a high verdict
>
> No bulk export available, or exports in a proprietary format only. Either one caps the verdict at high no matter how clean the other four dimensions look.

The reasoning is that these two conditions describe restrictive lock-in directly: complete exports are unavailable, prohibitively expensive, or slow, and contract terms make leaving commercially irrational. A second override applies when core business logic is bound to a proprietary black box. A vendor can score well on egress and standards and still be un-leavable if the thing you cannot export is the thing you cannot rebuild.

Map the combined result to a verdict with this two-variable read: how portable is the data and API, and how large is the migration you would eat.

#### The switching-cost verdict

Horizontal axis runs from Low portability to High portability. Vertical axis runs from Small migration to Large migration.

| Quadrant | What it means |
| --- | --- |
| High: portable but heavy | Accept only with a funded exit plan and named migrators |
| Low: portable and light | Safe to build on; re-check at renewal |
| High: locked and heavy | Refuse or renegotiate before any build |
| Medium: locked but light | Accept if the strategic trade is good and priced |

*Place the vendor by data/API portability against the size of the migration you would eat.*

A vendor that is portable and light is a low. A vendor that is portable but heavy, or locked but light, is a medium you can accept if you price the trade. A vendor that is locked and heavy, or that trips any override, is a high you refuse or renegotiate.

## How this goes wrong: seven false verdicts

The most valuable part of the rubric is knowing where it lies to you. Each failure mode below has produced a wrong verdict, and each has a check that catches it.

- **"Free egress" theater.** A vendor advertises free exit, but the ban covers switching egress only, and egress you incur during normal operation remains chargeable. A provider has every incentive to classify your exit traffic as ordinary usage. *Check: read whether the waiver is scoped to account closure only.*
- **Export API exists but is thin.** A documented endpoint that omits configs, permissions, or historical data is a false low. *Check: export a test tenant and diff it against the live system.*
- **Standard "supported" in name only.** S3-compatible or OTLP support may cover a subset of operations. *Check: run the vendor's own conformance test, not the marketing page.*
- **Format looks open, semantics are closed.** A JSON export with an undocumented schema still needs reverse-engineering. *Check: can a second engineer re-import it elsewhere without vendor help.*
- **Auto-renewal eats the Data Act benefit.** Letting an auto-renewal roll past 12 January 2027 risks years tied to old clauses. *Check: renewal date versus the deadline.*
- **Commodity treated as lock-in.** Over-scoring stable commodities wastes effort. Email delivery, DNS, CDN, and object storage are commodities where the major providers are all competent and stable; betting on AWS S3 is not a risky lock-in. *Check: is there a drop-in substitute today.*
- **Two graders, two verdicts.** If two engineers score the same vendor differently, the rubric's thresholds are underspecified. *Check: reconcile on the exact artifact that split them.*

> **Watch out:** The convergence trap
>
> Managed-service prices have converged - EKS and GKE both charge $0.10 per cluster-hour, about $73/month - so price is no longer a lock-in signal. That is by design. Once compute is a dead heat, the exit-cost difference lives entirely in data and API portability, which is exactly where graders forget to look.

## Closing the assessment and keeping it current

Before you record a verdict, run the checklist. It exists to catch the false lows above, where a vendor looks leavable on the marketing page and is not in practice.

#### Before you record the verdict

- [ ] A dependency inventory names every function that breaks if the vendor changes terms.
- [ ] The bulk export endpoint has a URL and a named output format, verified on a test tenant.
- [ ] Each open standard is marked present or absent with a link, confirmed by a conformance test not a marketing claim.
- [ ] A second engineer re-imported the export format elsewhere without vendor help.
- [ ] Egress is captured in $/GB and the exit clock in days, with any free-exit waiver checked for account-closure scope.
- [ ] A migration timeline band is named with its strategy, and the labor to execute it is confirmed to exist in your market.
- [ ] The override check is recorded, and two graders agree or the disagreement is logged and reconciled.

**Switching-cost score sheet**

```
Vendor: __________
Data export (1-3): __   artifact: __________
API uniqueness (1-3): __   artifact: __________
Open-standard conformance (1-3): __   standards: __________
Proprietary format risk (1-3): __   format: __________
Contract & egress terms (1-3): __   $/GB: ____   exit clock (days): ____
Raw total (5-15): __
Override check: no bulk export? [ ]   proprietary format only? [ ]   core logic in a black box? [ ]
Migration band: __________ (rehost / replatform / refactor)   estimate: ____ months
VERDICT: [ ] Low   [ ] Medium   [ ] High
Second grader verdict: __________   reconciled on: __________
```

*One row per dimension, then apply overrides. Paste into your build-decision doc verbatim.*

Two things date this score, so re-check them on a schedule. The first is regulation: the Data Act's switching-fee ban takes effect 12 January 2027, and any vendor assessed before then should be re-scored on egress and contract terms after that date, with renewal timing checked against the deadline. The second is the vendor's own conformance: a standard supported over a subset today may be complete next quarter, or a clean export may quietly drop a field. Re-run the format and conformance checks at each renewal, and re-run the labor check whenever you plan a new market, because the right to leave is only as real as the people you can hire to execute it.

## Frequently asked questions

### How do I assess vendor lock-in risk before signing anything?

Grade five dimensions from public artifacts: data export, API uniqueness, open-standard conformance, proprietary format risk, and contract and egress terms. Score each 1 to 3 from the vendor's own docs, then apply two overrides that force a high verdict: no bulk export, or exports in a proprietary format only. The whole assessment takes about three engineer-days per vendor and produces one comparable exit-cost number you can defend.

### What egress cost counts as a high lock-in signal?

First-tier egress at $0.12/GB, GCP Premium Tier's rate, sits in the high band; AWS at $0.09 and Azure at $0.087 are medium; zero-egress storage like Cloudflare R2 at $0.00 and Oracle after its 10 TB free tier are low. At 10 TB, the exit cost ranges from $1,137 on GCP to $0 on R2. Treat per-GB rate as a pure multiplier on your fixed exit volume.

### Does the EU Data Act mean I no longer need to worry about lock-in?

No. The Data Act caps the notice period at two months plus a 30-day transitional period and removes switching egress fees from 12 January 2027, but the fee ban covers switching egress only; operational egress stays billable. The real residual cost is re-instrumentation and reformatting, and a refactor of a large system still runs 6 to 18 months. The regulation grants the right to leave faster than most systems can actually move.

### What open standards should I check for when scoring API portability?

Four named signals move the score down: S3-compatible object storage, OTLP/OpenTelemetry for observability, an OpenAPI-described REST interface, and Kubernetes for portable orchestration. OpenTelemetry is load-bearing because it lets you instrument once and switch backends without touching application code. Verify each by running the vendor's own conformance test, not the marketing page, because a standard can be supported in name over only a subset of operations.

### Why do two engineers sometimes score the same vendor differently?

When two graders land on different verdicts, the rubric's thresholds are underspecified for that vendor. Reconcile on the exact artifact that split them, usually a format that looks open but has an undocumented schema, or a standard that is supported over only a subset of operations. The second-grader check exists precisely to surface these gaps before the number goes into a build decision.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/switching-cost-score-vendor-lock-in*