An internal team and a packaged-software vendor both pick the same message serialisation format this quarter. Two years later the internal team replaces it in a single sprint. The vendor still supports it and expects to for another decade - an ERP vendor in SAP's position has customers whose 12-year-old integrations must keep working across a major release. Nothing about the technology differs. What makes the same choice a different decision for each of them?

The mechanism

The cost of changing a technology is set by the dependents you cannot redeploy, not by the technology. The internal team's callers are in repositories it can see, built by teams it can talk to, deployed on a cadence it shares. Replacing the format means finding n call sites, changing them, and shipping. The work is bounded and knowable on the day of the decision.

The vendor's dependents are customer integrations written by people it has never met, running on release versions it does not control, on schedules set by the customer's own change freeze. It cannot count them, cannot test them, and cannot make them move. So its choice is not "use this format", it is "support this format for as long as any customer runs code that speaks it" — which for enterprise software is measured in a decade or more.

The consequence people miss

This is not a vendor-only distinction, and that is the useful part. The same asymmetry appears inside an ordinary enterprise the moment a technology choice reaches something that cannot be redeployed on demand:

• A data format written into nine years of archived files. Changing the writer is a sprint; being able to read 2017's archive is forever.
• An identifier scheme printed on customer invoices or embedded in partner systems. The dependents are outside the release train entirely.
• A public or partner API. Every consumer you did not build is a dependent you cannot move.
• Anything an auditor or regulator has been shown. The dependent is a document, and documents do not refactor.

Reversibility is therefore not a property of a technology. It is a property of who else depends on the choice and whether you can make them change. Two teams making the same choice can be making a one-sprint decision and a ten-year decision.

What to do with this before choosing

Count the dependents you cannot redeploy on demand. If the count is zero, choose quickly, write one paragraph about why, and expect to revisit it — optimising that decision is wasted effort. If the count is above zero, the choice deserves the scrutiny of its longest-lived dependent, and the specific thing to look for is a written compatibility story: field numbering or tag-based schema evolution rather than positional layouts, explicit version negotiation, and a documented statement of what the format's maintainers consider a breaking change.

When this is the wrong answer

When the migration is genuinely mechanical and machine-verifiable. A format change that a codemod applies across 300 repositories with a compiler proving completeness has few of these properties, and treating it as a decade-long commitment slows the organisation for nothing. The flip condition is whether a machine can find and fix every dependent. If it can, the dependent count that matters is zero however large the estate.

Common weak answers

• "The vendor has more users so the stakes are higher." Scale is not the mechanism. A ten-person company with one partner integration it cannot change has the same problem in miniature.
• "Pick the standard with the longest history." Longevity correlates with compatibility discipline but does not create it. What matters is the schema evolution rules and whether breaking changes are declared.
• "Abstract behind an interface and stay free." An interface hides the format from your own code and does nothing about the bytes already on the wire or on disk. Abstraction protects callers you control; it does not protect data you have already written.