How do you handle model deprecations and version changes from providers?

Process

1. Inventory: a registry of model usage by feature, team, prompt version and volume.
2. Watch announcements: subscribe to provider deprecation notices; calendar the retirement dates.
3. Migration plan per feature:
   • Run eval suites on the candidate replacement models.
   • Tune prompts for the new model (behavioural differences: verbosity, tool-calling style, refusals).
   • Compare cost and latency.
4. Rollout: shadow → canary → full; monitor quality, latency and cost.
5. Don't wait for the deadline: start migrations early; deprecation deadlines cluster.

Aliases vs pinned versions: aliases (e.g. "model-latest") auto-update, which is convenient for prototypes but dangerous in production. Silent behaviour changes break workflows (see Q34).

Related

• Previous: Q13. How do you track and attribute LLM costs in an organisation?
• Next: Q15. How should prompts, outputs and traces be governed in terms of retention and access?