We are migrating from one provider to another

What is actually happening

The schedule is not yours. A migration that starts because a provider published a date is running on that provider's calendar, and the first job is to read the date rather than to estimate it. The three providers we track publish three different commitments, and they are separate promises by three companies rather than a shared standard. Anthropic says customers with active deployments get at least 60 days[src] before a publicly released model is retired, and its page states that partner platforms set their own schedules.[Anthropic] OpenAI says at least 6 months[src] for a generally available model, at least 3 months for specialized variants, and for preview models much shorter notice, such as 2 weeks, with no minimum committed.[OpenAI] Google says Gemini preview models will be deprecated with at least 2 weeks[src] notice.[Google]

Dates move, and retirements land. Google announced on 2 April 2026 that Vertex AI retirement dates for three Gemini 2.5 models had been updated to 16 October 2026[src].[Google] Anthropic notified developers on 14 April 2026 that Claude Sonnet 4 and Claude Opus 4 would be retired, and both were retired on 15 June 2026[src].[Anthropic] Pinning to a dated snapshot buys time rather than permanence: OpenAI announced on 11 June 2026 that the gpt-5-2025-08-07 snapshot would be shut down on 11 December 2026[src].[OpenAI] Each of these sits in the change log with the provider's own source.

Then there is the part that surprises teams. Behaviour differences survive a prompt port. The prompt you are carrying across was shaped against one model, by people iterating until it behaved, and that shaping is not a property of the text alone. The port compiles, the calls succeed, and the outputs are not the same on the cases at the edges of your traffic. Some of the friction is even more mechanical: Anthropic deprecated the temperature, top_p and top_k parameters from Claude Opus 4.7 onward, and a non-default value now returns a 400 error, which is caller code broken with no model swap on your side.[Anthropic]

A migration is therefore two changes landing together, the model and the platform, with a prompt in between that was never neutral. The only way to read it is to have measured the thing you are leaving before you leave it.

What to do this week

Day one is an inventory, and it is longer than anyone expects. Model ids hide in batch jobs, in internal tools, in a fallback path, in a notebook that quietly runs weekly. A migration that misses one of those does not fail on cutover day, it fails later, which is worse. The per-provider change log pages exist to make this cross-check quick.

Day two turns the inventory into a schedule by writing each published deadline next to each id, from the provider's own page rather than from a summary. Preview ids and general release ids get different columns, because the notice you get differs by class and by platform. The OpenAI change log is the same information organised by announcement.

Day three is the step teams skip and then regret. You baseline the feature on the model you are leaving, on a pinned golden dataset (a fixed set of labelled inputs and expected outputs, versioned, that every run scores against) version, while it is still serving. Once the old model is gone, there is nothing left to compare against, and every later argument about whether the migration cost you anything becomes unresolvable. Day four runs the ported prompt on the target model against that same dataset and the same scorer (a function that turns one output into a number or a pass and fail verdict) set. Day five reads the cases that changed verdict and converts them into work, which is usually prompt work rather than a change of destination. Our rerun and dataset protocols set out both runs in full.

What happens without evals

We have no cited case for this situation. Our evidence set holds no published post-mortem of a migration that regressed a feature, and we will not invent one.

The mechanism is easy to state and hard to argue with. Without a baseline on the model you are leaving, the migration is scored by whoever notices something. A regression (a case that passed before the change and fails after it) on ten percent of your traffic looks like noise for a fortnight, then looks like a support trend, then gets attributed to the new provider with no measurement behind the attribution. Meanwhile the old model has retired, so the comparison that would settle it no longer exists. The dated retirements above are the part of this that is not hypothetical: once the id stops serving, the option to measure it is gone.

Which plan fits and why

Up to three features at $4,400 a month fits because migrations rarely arrive one feature at a time. A deprecation notice usually touches everything on that provider, and the plan covers three features, 1,500 dataset items across them, 12 scheduled runs a month, a 5,000 request production sample, and a call every two weeks while the move is live. Flagged changes come back within 2 business days, and every tracked provider update triggers a rerun within 2 business days of the provider's announcement.

The honest limit: the plan does not include a CI gate or same-day reruns, and coverage is bounded by the dataset and the plan. We watch the providers, models and platforms you tell us your features call, so an id that never made it onto the day one inventory is not being watched by us either. Each feature needs its own eval baseline before the reruns mean anything, and if the migration is really an open question about which model wins, read we cannot decide between two models first.