A company that builds on a database can generally assume the database will be there next year, behaving as it did. That assumption is so deeply held that it rarely gets stated, and it underwrites most of how enterprise software is planned.
Model providers do not offer it. Models are deprecated on vendor timelines, sometimes with a year of notice and sometimes considerably less, and the replacement is not a drop-in. It is a different system with different behavior that happens to accept the same API call.
Why a version bump is not a version bump
Conventional software dependencies break loudly. A removed function throws an error, a test fails, and the failure points at its cause. Model changes break quietly. The new version returns a plausible answer that differs from the old one in ways no type checker detects: a classification boundary shifts, a summarization style changes, a prompt that reliably produced structured output starts producing it with occasional variation.
Anything built on top of that behavior inherits the drift. Prompts tuned over months against one model's quirks are not portable. Evaluation thresholds calibrated to one version's error profile mean something different against another. Downstream systems that learned to expect a particular output shape encounter a new one. Teams that have been through a forced migration describe the work as a rebuild of the surrounding scaffolding rather than a swap.
The cost lands unevenly. Organizations running smaller models they host themselves control their own upgrade timing, which is turning out to be a more significant advantage than the cost argument that usually justifies that choice. Companies on frontier hosted APIs get capability they could not otherwise obtain, and accept a dependency whose lifecycle belongs to someone else.
Procurement has started to respond, which is the clearest sign that this has stopped being a research concern. The contract terms corporate buyers are pushing for now routinely include minimum deprecation notice, version pinning for a defined period, and access to a prior version during a transition window. Those are unremarkable provisions in any other category of enterprise software, and the fact that they had to be negotiated specifically tells you how new this market still is.
The internal discipline that helps is unglamorous and mostly absent: maintain an evaluation suite that captures what the system is actually supposed to do, run it against candidate replacements, and treat the results as the migration criterion. Organizations that have this can assess a new model in days. Organizations without it, which is most of them, are in the position of having deployed something whose correctness they cannot re-verify, which is a problem that predates deprecation and merely becomes visible because of it.
The cost compounds for organisations that deployed widely without measuring, since a migration forces the question of whether the replacement performs adequately and the evaluation infrastructure to answer it was never built. A forced migration is where that debt comes due, all at once and on someone else's schedule.
The strategic question underneath is one that few companies have answered explicitly. Building on a frontier model means renting a capability that is improving faster than you could develop it, on terms that include the provider changing it. That trade is often correct. It is rarely made deliberately, which is the part worth fixing.
