Original practice question. The scoring rubric is our teaching guide. How we research and score answers
TL;DR: Announce with a generous, fixed timeline; recommend a specific replacement with evaluation evidence showing how behaviour differs; provide migration tools (side-by-side testing, prompt guidance, cost comparisons); reach out directly to the largest and most dependent customers; send reminders at set intervals; and honour the date. Measure migration progress weekly and adjust support where customers are stuck.
How to approach it
Explain why deprecations are necessary (serving costs, focus, safety), then design communication, replacement guidance, tooling, customer segmentation and the timeline. Emphasise predictability.
A strong answer
Why deprecate. Old models consume serving capacity, need security and safety maintenance, and split engineering attention. But for customers, a deprecation is forced work with risk, since the new model will behave differently.
Timeline and communication.
| Milestone | Action |
|---|---|
| Announcement | Date fixed, replacement recommended, migration guide published; generous lead time, measured in months |
| Midway | Reminders to remaining users; direct outreach to large accounts |
| Final month | Weekly reminders; warnings in API responses or dashboard for calls to the old model |
| Retirement | Model turned off on the stated date; clear error messages pointing to the replacement |
Predictability matters more than length: developers plan around dates. Moving a deadline repeatedly teaches customers to ignore deprecation notices.
Replacement guidance with evidence. Publish how the replacement compares: quality on common tasks, known behaviour differences (output format, length, refusals), latency, and cost. Note tokenization changes that affect cost; Anthropic, for example, documents that the tokenizer in Claude 4.7 and later models produces about 30% more tokens for the same text, as of 6 November 2026.
Migration tooling.
- Side-by-side testing: run the same prompts on old and new models and compare outputs.
- Prompt adaptation guidance for common patterns.
- Cost estimator using the customer's actual traffic.
- Extended free or discounted testing quotas on the replacement.
What the labs actually do, as of 6 November 2026. Three published policies show the range of choices.
| Provider | Notice | What happens on the date |
|---|---|---|
| Anthropic | At least 60 days for publicly released models; Claude Sonnet 4.5 was notified on 30 September 2026 for retirement on 30 November | Requests to the retired model fail; a usage export by API key and model shows customers where they still call it |
| OpenAI | At least 6 months for generally available models, 3 months for specialised variants, as little as 2 weeks for previews | Shutdown, with dedicated capacity available to some customers through sales |
| Google Gemini API | Gemini 2.5 Pro and 2.5 Flash deprecated on 2 November 2026 | From 1 December 2026, requests route automatically to Gemini 3.8 Flash and 3.5 Flash-Lite, billed at the new model's rates |
The last row is a different design. Automatic routing means nothing breaks on the day, and also that behaviour and price change under customers who never tested the replacement. A hard failure is louder and more honest about the change. Pick one deliberately, and if you auto-route, say so in every reminder, with the new price.
Customer segmentation.
| Segment | Support |
|---|---|
| Small usage, simple prompts | Self-serve guide and reminders |
| Large or business-critical usage | Account team outreach, migration assistance, early access to help |
| Regulated customers needing revalidation | Earlier notice where possible, documentation for their validation processes |
| Customers with fine-tuned variants on the old model | Path to re-fine-tune on the replacement, with support |
Measuring progress. Weekly share of traffic and customers still on the old model, broken down by segment; support tickets; error rates on the replacement after migration. Focus help where migration stalls.
What interviewers probe next
"A major customer says they cannot migrate in time." Understand the blocker. If it is real (regulatory revalidation), consider a time-limited extension for that customer under a separate agreement, without moving the public date.
"Why not keep old models running forever?" Cost, security maintenance and focus. Anthropic's November 2025 deprecation commitments state the cost directly: serving models publicly scales roughly linearly with the number of models. Clear lifecycle policies published in advance help customers plan.
"Should we route callers of the retired model to the replacement automatically?" Only for customers who opt in, or with the price and behaviour change named in every notice. Silent routing turns a deprecation into an unannounced model change, which is the thing the deprecation process exists to prevent.
How it's scored
| Signal | Weak | Hire | Strong Hire |
|---|---|---|---|
| Communication | An announcement | Timeline with reminders | Fixed date honoured, staged reminders, in-API warnings |
| Migration support | Docs | Recommended replacement | Evidence on behaviour differences, side-by-side tools, cost estimator, segment-specific support |
| Management | Not tracked | Usage tracking | Weekly progress by segment, targeted help, handling of special cases without moving the public date |
Common mistakes
Short notice periods that force rushed migrations.
Recommending a replacement without describing how its behaviour differs.
Repeatedly moving deadlines.
See launching a model and model migration.