Record when the old model can be retired

Identify what still depends on it

List active conversations, paused workflows, evaluation baselines and fallback routes that reference the previous configuration. Completed historical reports may only need retained metadata and outputs, while paused tasks may still require compatible execution.

Check whether the old endpoint has an announced lifecycle or configuration limit using the provider's current documentation. Do not rely on an assumed indefinite rollback window.

Keep the model dependency separate from workflow code. Some saved operations can finish without another model call, while others require the original prompt and tool contract to continue meaningfully.

Define the observation window

Agree what evidence is needed before removing the prior route: representative task coverage, acceptable production outcomes and resolution of material regressions. A calendar date alone may be insufficient if important workloads have not occurred during the window.

Name who can extend the window and why. Keeping every previous configuration forever creates operational clutter and can leave unused credentials or data paths active.

Document the fallback after retirement. It may be another tested configuration, a restricted capability or a manual process. Do not leave support expecting a rollback that no longer exists.

Retire with a dependency check

Before disabling the old endpoint or removing credentials, confirm no supported run or fallback still needs it. Resolve long-paused tasks through the agreed migration or closure process.

Preserve historical release records according to their retention rules, without retaining unnecessary sensitive payloads. Record the retirement date and the replacement recovery path. The handover is complete when support knows both how to restore behaviour now and what will change once the old configuration is no longer available.