Model Deprecation Strategy for Self-Hosted

Self-hosted gives you control over model lifecycle — including how long to keep an old model serving. Hosted APIs deprecate on their schedule; self-hosted lets you choose. The discipline is to have a strategy, not just "forever, until it falls over".

When to deprecate

• Better successor: new model with measured quality lift on your eval harness
• Security: known vulnerability in older model / framework version
• Licence change: original licence becomes incompatible with your use
• Maintenance burden: increasingly hard to keep running on current GPU / driver / vLLM versions
• Cost: better cost economics on a newer / smaller model

Plan

Standard deprecation timeline:

1. T-90 days: announce deprecation; document migration path; offer office hours for affected teams
2. T-60 days: dual-run old + new in production; eval harness compares
3. T-30 days: route 50% traffic to new model; monitor
4. T-7 days: route 95% to new; old kept warm
5. T-0: cutover complete; old version stays warm for emergency rollback
6. T+30 days: decommission old version

Migration

• Eval harness comparison: new model meets / exceeds quality bar on representative tasks
• Prompt template changes: some models need different prompt patterns; document + provide examples
• API contract: keep external API contract stable; absorb model-specific differences server-side
• Performance characteristics: latency, cost, throughput differences communicated to consumers

Verdict

Self-hosted gives you control over model lifecycle — use it. Document a deprecation strategy, communicate timelines, dual-run during cutover, keep eval harness honest. The discipline pays off when consumers trust your migration cadence and infrastructure stays maintainable long-term.