The Portability Audit: What It Costs to Leave a Vendor

These are two different problems with two different fixes. Proprietary API lock in means your code calls a vendor specific interface that has no direct equivalent elsewhere, so leaving means rewriting integration code. Data gravity means your data lives in a format or a location that makes moving it slow and expensive, even if the API itself is standard. A vendor can score low on one and high on the other. Object storage with a standard, widely compatible API has low API lock in but can still have real data gravity once you're storing a large volume and egress fees start to matter.

Audit both separately for each major dependency, because the fix for one doesn't help with the other.

The recurring bill is the cost you already see. The exit cost is the one nobody prices until they need to. For each major dependency, find the actual egress fee per gigabyte for pulling your data out, and whether the vendor offers any bulk export tooling or if you'd be paginating through an API for weeks. Say your primary database holds several terabytes of production data. At typical cloud egress pricing, moving that out is a real, budgetable figure, not a footnote, and it should show up in any vendor comparison alongside the monthly subscription cost.

Getting this number in writing, even informally, turns lock in from a vague fear into a line item you can plan around.

The cheapest way to learn your real exit cost is to actually migrate something low stakes off a dependency while there's no pressure to do it. Pick a small, non critical service and move it to an alternative, or at minimum export its full dataset and confirm you can reconstruct it elsewhere. This surfaces the undocumented gotchas, a proprietary field type, an implicit ordering your code relies on, a background job that assumes the vendor's specific latency profile, while the cost of being wrong is a delayed side project instead of a failed production cutover under a renewal deadline.

Teams that skip this step find out about these gotchas during the actual high stakes migration, which is the worst possible time to learn them.

Not every vendor relationship deserves the same level of exit planning. Score dependencies on two axes: how hard it would be to leave, and how much pricing power the vendor currently holds over you. A dependency that's cheap to leave and where the vendor has little pricing power needs no special attention. One that's expensive to leave and where the vendor has raised prices before is where a real portability plan earns its cost. Put this scoring somewhere the team actually revisits, not a document written once during a single planning cycle and never opened again.

This is also the right lens for deciding where to invest in abstraction layers versus where a vendor specific integration is fine as is.

Vendor negotiations go differently when you already know, with real numbers, what it costs to leave versus what it costs to stay. Before any contract renewal for a dependency you scored as high risk, write down the actual exit cost you found in the audit and treat that as your walk away price in the negotiation. Without that number, a price increase during renewal negotiations gets evaluated on instinct instead of on a real comparison, and vendors know it.

The audit only pays off if the numbers it produces actually show up in the room when the contract gets negotiated.

A portability audit that takes a month to run the first time will never get run a second time, and a stale audit is nearly as risky as no audit at all once egress pricing or export tooling changes underneath it. Keep a simple, living record per dependency: the egress cost, the export path, the score, and the date it was last checked. Updating that record after a small exit test or a pricing change takes minutes. Rebuilding it from scratch every couple of years, because nobody kept it current, takes days and usually happens right when there's least time to spare for it.

Keep one record per dependency with these fields:

• The egress cost per gigabyte for pulling your data out, taken from the vendor's current pricing rather than memory.
• The export path, meaning whether bulk export tooling exists or you would be paginating through an API for weeks.
• The score, combining how hard the dependency is to leave with how much pricing power the vendor holds over you.
• The date it was last checked, updated after each small exit test so the record never goes stale.