Portability Tax

A company bans managed services so it can move providers later. It self-hosts Postgres, Kafka and an object store on Kubernetes and maintains a wrapper over two infrastructure-as-code providers. It has never run anything on a second provider, and it has paid for the option every month for four years.

The portability tax is that payment. It is not the cost of migrating; it is the cost of staying ready to migrate, and unlike a migration it never ends. Naming it as a line item changes the conversation, because the comparison people make — "lock-in is dangerous" against "portability is prudent" — weighs a risk against a virtue instead of weighing two numbers.

Why it matters

The arithmetic is usually decisive once anybody does it. The standing operational load of a self-hosted database, message bus and object store at moderate scale is realistically two to four engineers: major version upgrades, partition arithmetic, backup verification. Fully loaded that is roughly $400k to $800k a year, every year. A one-off migration of the same estate is a project of a few quarters, costed once, and most companies are never asked to perform it.

The second cost is a ceiling rather than a bill. A portability layer abstracts over the parts of two providers that differ most — identity, networking and the managed-service surface — so it converges on whatever both support. Every capability on one side and not the other is unavailable by construction, including the ones that would have removed the operational work being paid for.

The third cost is visible only in hindsight: the abstraction becomes the thing that has to be migrated.

Implementation patterns

These are the controls that deliver what portability promises without the recurring charge.

• A costed exit plan, written and refreshed annually: what would move, in what order, at what cost, over what time. It is the artefact boards and auditors actually ask for.
• One rehearsed exit step. Restore the production database into a second provider's managed equivalent once a year and time it. A week of work that replaces an assertion with a measured number, and the step that reveals the real blocker is usually identity, secrets or DNS rather than data.
• Portability through standard interfaces, not abstractions. Postgres as a wire protocol, the S3 API as the storage interface, containers as the packaging format, open table formats on disk. Portability from a standard interface is free; portability from a layer you maintain is not.
• Data-format discipline, which matters more than avoiding a provider's compute, because data is the part that cannot be re-created.
• Commercial controls instead of technical ones, since a credible second quote moves price more reliably than an abstraction layer.

Industry example

The clearest demonstrations that building beats buying come from platforms whose data is the product. Hugging Face's Hub distributes very large model and dataset files, originally through Git LFS, and moved to Xet, a storage layer that deduplicates at the chunk level using content-defined chunking at roughly 64 KB, so that changing part of a large file transfers only the chunks that changed. That is a bespoke storage system built in place of a generic one, and it is the opposite of a portability layer: it exists because a measured property of the workload — multi-gigabyte artefacts differing in small regions — made the generic option expensive, not because neutrality was a goal.

The reasoning is what transfers, not the system. Building is justified by a workload property you can measure and the managed option handles badly. Provider neutrality is not such a property; it is a wish about the future.

Failure scenarios

• The tax exceeds the risk and nobody notices, because the avoided migration is hypothetical while the headcount is real and buried in a platform team's budget.
• The exit claim is never tested, so "we could move in a quarter" turns out to be a year at the moment it matters.
• Self-hosted durability nobody can evidence, where the object store has no verified restore and the availability claim is aspirational, which is worse than the lock-in avoided.
• The abstraction ossifies, as two years of provider feature releases go unadopted because any of them would break neutrality.
• Hiring friction, as engineers arrive able to use managed services and spend a quarter learning a bespoke wrapper.

Trade-offs

When not to use it

The tax is sometimes the correct purchase, and it is worth being precise about when. Pay it when a contract or a regulator requires the workload to run in a second provider or a sovereign environment — parts of defence, public sector and financial services — because then neutrality is a condition of sale rather than an engineering preference, and the lowest common denominator is the specification. Record that in the decision record so a later team does not optimise away a commitment.

Pay it, too, where one provider genuinely cannot supply the capacity or the hardware a workload needs on the timeline required, which is the one justification that does not rest on a hypothetical. Do not pay it to avoid egress charges, to improve a negotiating position, or because lock-in sounds risky; each has a cheaper control, and the first two are commercial problems wearing an architecture costume.

Interview question

Q: You join a company that has banned managed services for portability and has never run on a second provider. The platform team of four is fully occupied running Postgres, Kafka and an object store. How do you evaluate whether the policy is right, and how would you change it without losing the room?

What a strong answer covers: quantify both sides — platform headcount and forgone capability against a modelled one-off migration — and ask for evidence the risk ever materialised: the last three incidents and the last contract renewal. Separate the three risks bundled into "portability" (pricing power, contractual exit, provider failure) and match each to its cheapest control. Propose a trade rather than a reversal: adopt the managed database first, fund an annual exit rehearsal, keep the standard interfaces that cost nothing. Say explicitly what you would not change, which is what keeps the room.

Quick check

Quiz: A team says a portability layer reduces migration cost. What is the more accurate statement? Answer: it relocates the cost from a one-off project into a permanent recurring charge, and the layer itself usually becomes part of the eventual migration.

Flashcard: Which lock-in control costs about a week a year and satisfies most boards and auditors? — A costed exit plan plus one rehearsed step, typically a timed restore of the production database into a second provider's managed service, which yields a measured number instead of an assertion.