Your model retires before your system does
A hosted model can retire while the business service still depends on it. Record version dependencies, assign notice ownership and evaluate replacement paths before accepting the supplier lifecycle risk.
Trace the interfaces between applications and records before changing a system.
A hosted-model retirement notice gives the service owner a replacement decision. The affected identifier, deadline and proposed successor need to be connected to the organisation’s actual dependencies. A published notice does not establish that the right owner has received or acted on it.
The work can include interface changes, prompt review, local evaluation and a controlled release. Its size depends on the design and retained evidence. Record those dependencies before a notice arrives rather than assume that every replacement is either a simple setting change or a major rebuild.
Include supplier model lifecycles in the organisation’s change process. An inventory and a maintained evaluation set help scope the response. Portability can reduce some work, but it does not remove the need to assess the successor.
The mismatch, stated plainly
A business service may need to operate longer than a particular hosted version remains supported. OpenAI’s deprecations and Anthropic’s model lifecycle documentation describe provider-specific changes and dates. Check the affected product and contract instead of applying one assumed notice period to every model.
Make the replacement decision reviewable
Which service dependencies must change before the provider’s retirement date?
- Fixture
- The affected model identifier, supplier notice, caller inventory and maintained evaluation set.
- Procedure
- Confirm the notice and affected direct and indirect callers.
- Check candidate interfaces, prompts and required operating conditions.
- Compare candidates on the local evaluation and review consequential failures.
- Rehearse release and fallback, then record acceptance before the applicable deadline.
- Result to check
- A scoped replacement plan with evaluated outcomes and a named decision owner.
- Evidence limit
- This is a proposed migration method, not a delivery schedule or proof that a gateway makes replacement automatic.
- Next test
- Reassess material supplier or service changes and unresolved version-recording limits.
Representative method for this article, not a measured deployment result.
Which service dependencies must change before the provider’s retirement date? Evidence limit: This is a proposed migration method, not a delivery schedule or proof that a gateway makes replacement automatic.
Reviewed 2026-10-02
The method shown here is a proposed migration sequence, not a promised notice period or observed delivery schedule. Evaluation effort depends on the workload, interfaces and evidence. Begin with enough time to resolve failures and obtain the owner’s acceptance before the applicable deadline.
The two decisions that set the cost
| Built without these | Built with them |
|---|---|
| The model identifier appears in application code | Model selection is controlled, with affected callers and compatibility recorded |
| Prompts were tuned by hand against one model | Prompts are versioned artefacts with a recorded evaluation score |
| Quality after migration is judged by trying a few examples | Quality and uncertainty are evaluated on a maintained held-back set |
| Nobody knows which systems use the retiring model | The inventory lists model dependencies as dependencies |
The inventory should identify direct and indirect calls, maintained applications and still-running services. Source-code searches can support discovery but may miss configuration, supplier-managed components or runtime changes. Verify the dependency list through the relevant operating records.
What to put in place before the next notice
Record the available model identifier and version information with each consequential output. Providers may change behaviour within a service, and an identifier may not expose every change. Preserve supplier notices and monitoring evidence, and state where exact version pinning or reconstruction is unavailable.
Keep the original notice and the scope of the replacement evaluation with the change record. A later reviewer should be able to distinguish the supplier’s recommendation from the organisation’s acceptance of the successor.
The version of this that reaches procurement
Discuss lifecycle terms during procurement: notice of retirement, successor access for evaluation and disclosure of material changes. Check what the supplier actually commits to and where exceptions apply. These terms inform the migration plan rather than substitute for local evaluation.
Where a supplier cannot offer a requested commitment, assess the consequence for the intended use. Monitoring, restricted scope or an alternative may address part of the gap. The lack of a notice term does not prove that all behaviour is impossible to evidence, but it creates a dependency to record.
What this does not tell you
Self-hosting can move version retention and upgrade choices inside the organisation. It also introduces maintenance, hardware and security responsibilities, and may retain external dependencies. Compare the complete arrangement rather than assuming it removes every lifecycle constraint.
It also does not claim that every system needs the full apparatus. A prototype does not need a gateway. What it needs is an honest note in the design record saying that the model identifier is hard-coded, so that the person who industrialises it later knows what they inherited.
The service owner should confirm the models and versions in use, the notice route and the tested replacement or fallback. Record unresolved migration work and the person authorised to accept it. Keep that evidence current when the supplier or service changes.