The Model Deprecation Notice That Landed During Your Code Freeze

The email arrives on a Tuesday. The checkpoint your two largest features depend on enters a 90-day sunset. Your engineering org is in week two of a coordinated freeze for a different launch. By the time the freeze lifts, you will have under thirty days to revalidate two production features against a new model — and "revalidate" here means rebuilding the eval set, running shadow traffic, getting product sign-off, and shipping behind a flag that nobody is watching because the launch team is still ramping the thing the freeze was for.

This is not a rare collision. Major providers publish deprecation cadences measured in months, and every team running on hosted models has now seen one cycle. What teams have not absorbed is that provider deprecation is not an engineering event the way a library upgrade is — it is a scheduling event that arrives on a clock you do not control, and any roadmap that did not budget for it inherits the cost as a surprise.

The instinct on the receiving end is to argue with the timing. "We're in a freeze." "We have a launch in three weeks." "Can we get an extension?" Sometimes you can — provider account teams will quietly extend tier-one customers, and the published date is rarely the real date for accounts that ask. But the negotiation is not the lesson. The lesson is that your roadmap assumed provider lifecycles were external in the way weather is external, when they are actually scheduled, predictable, and possible to plan against.

The freeze policy was written for a different threat model

Most engineering freezes were designed to stabilize code during a high-stakes window — Black Friday, a regulatory deadline, a marketing-driven launch. The mechanism is "stop changing things so nothing breaks." The policy assumes the threats are internal: a careless merge, a config drift, an untested optimization that takes down checkout on the busiest weekend of the year.

That mental model handles internally-initiated risk well. It handles externally-initiated risk badly, because the freeze can only suppress changes the team itself controls. A model sunset is a change to your system that was authored by your vendor and propagates the moment their date passes. The freeze cannot suppress it. The freeze can only suppress your response to it.

Worse, the freeze creates a coordination cost on top of the technical work. The team that should be migrating the model is also the team that agreed not to touch production. Getting an exception requires conversations with whoever owns the launch the freeze exists to protect, and those conversations happen at the moment that team is least able to spare attention. The path of least resistance is "we will get to it after the freeze." The path of least resistance is also how you arrive at the 30-day cliff.

A freeze policy that does not name external deprecation as a permitted exception is a policy that pretends provider clocks do not exist. They do. They publish in advance. The policy can be updated.

Deprecation cadence is a roadmap input, not a surprise

The fastest fix is the cheapest one: treat the provider's published deprecation pattern as a planning input on every quarterly horizon. The data is public. Each major hosted-model vendor publishes a deprecation page that lists historical sunset windows, current notice periods, and the live deprecation set. Reading those pages quarterly tells you, with reasonable fidelity, what your migration calendar looks like for the next year.

The reading produces three buckets:

• Models you depend on that are already deprecated — these have a hard date. Treat them as launches scheduled for that date, with all the planning that implies.
• Models you depend on that are still legacy-flagged but not yet deprecated — these are 60-to-180 days away from a hard date. Reserve capacity for them in the next planning cycle.
• Models you depend on that are still active — these are the ones whose deprecation will surprise you next. Pick the most likely candidates based on the vendor's release cadence and assume a deprecation event per major model per year as a planning baseline.

The number of teams that do this exercise is small. The number that should is every team running production traffic on a hosted model. The exercise takes an afternoon and produces a year of calendar items that would otherwise arrive as emails during freezes.

The deprecation-watch role nobody owns

Loading…