When the Model You Built On Gets Retired: Deprecation Risk Reaches the Product Layer

Software has always carried dependency risk, and the industry developed reasonable defences: pin a version, vendor the library, budget for migration when a major release lands. Building a product on a hosted AI model introduces a variant of that risk with a property the older kind lacked — the dependency can be withdrawn on the provider's schedule, and the organisation depending on it cannot keep running the old version privately, because it never had a copy of it in the first place. The migration problem is not primarily about capability, which is what makes it easy to underestimate. A successor model that scores better on every published benchmark can still be a breaking change for a specific product, because the product was tuned against the predecessor's particular behaviour: the prompts that reliably produced the right output format, the failure modes the surrounding code learned to catch, the tone the customer base grew accustomed to. Behaviour, not capability, is the interface — and behaviour is exactly what no version guarantee covers. The teams that have handled deprecation cycles smoothly share a small number of practices, none of them exotic. They keep an evaluation set built from their own historical production cases rather than public benchmarks, so a candidate replacement can be scored on the work the product actually does. They isolate model interaction behind a single internal interface rather than scattering direct calls across the codebase. And they treat the announced deprecation window as the point to start migrating rather than the deadline to finish by, because the discovery of behavioural drift always happens later in the process than planned. The strategic response some organisations have drawn is to keep a smaller open-weight model viable as a fallback for their most critical paths — accepting lower capability in exchange for a version that cannot be retired by someone else's product decision. That is a real hedge with a real cost, and it is not the right answer for every workload. But it reframes the question usefully: the relevant risk was never whether a hosted model is good enough today, it is what happens to the product on the day the provider decides that particular model has reached the end of its life.