If your software uses AI to read invoices, answer customer questions or update business records, a model retirement can change how those features work. Your team has to choose a replacement, check it against real tasks and release any necessary application changes while customers continue using the product.

Anthropic has scheduled Claude Sonnet 4.5's retirement on the Claude API for 30 November 2026. Its deprecation documentation explains that requests to retired models fail. Partner-operated services, including Amazon Bedrock and Google-managed Claude deployments, can have different schedules.

For CTOs and engineering leads, the useful question is how to establish that a replacement can perform the work customers already depend on, and what must change before it reaches production.

Find every workflow that uses the model

Start by identifying where the model is called, including background jobs, document processing, customer-specific configurations and fallback paths. Record the provider, exact model identifier, request settings, prompts, output format and any tools the model can use.

This often reveals that one model supports several quite different jobs. An assistant drafting a support response and a service extracting payment details need different acceptance criteria, even when both use the same API.

The inventory should connect each integration to a business owner and a technical owner, so someone can decide whether a change in behaviour is acceptable and someone can implement the necessary corrections.

Compare results against the application's actual job

A useful evaluation set contains representative inputs, expected outcomes and examples that previously caused problems. Include incomplete documents, ambiguous requests and cases that should be sent for human review.

For an invoice application, that could mean checking supplier identity, currency, tax, totals and missing fields. Valid JSON is only one check, because a correctly formatted response can still contain the wrong amount.

Agree what release approval requires before tuning the replacement:

• Correct results for business-critical fields and decisions.
• Appropriate handling of missing information and requests outside the feature's scope.
• Correct tool selection and arguments where the model can request an action.
• Response times and completion costs within the application's operating limits.
• A workable route for cases the model cannot complete.

Anthropic's evaluation guidance describes how to define measurable, task-specific criteria. Keep some examples separate from prompt tuning so the final assessment includes cases the team has not repeatedly optimised against.

Check the integration as well as the answers

A replacement can require changes to request settings, response handling or the way the application asks the model to call functions. Anthropic's Sonnet 5.5 migration guide, for example, explains which settings must be removed and how existing code needs to handle the new model's responses.

Review the guide for the actual source and destination models, then test the SDK, API version, streaming, timeouts and error handling used by the application.

Costs also need measuring across completed workflows. A lower token price may be offset by longer responses, additional tool calls or more retries. The relevant comparison includes the work required to obtain an acceptable result.

Where practical, keep provider-specific request handling in a dedicated integration layer. Our article on where AI belongs in a .NET application architecture explains how that boundary can make subsequent changes easier to contain.

Release with a recovery route that will remain available

Version the model configuration, prompts, tool definitions and application changes together so a production result can be traced to the combination that produced it.

Before switching all traffic, compare results in a controlled environment or through a limited rollout. If requests are replayed for comparison, disable external actions so testing cannot create duplicate records or messages.

The recovery plan must use a model or workflow that will remain available after retirement. Depending on the feature, that may mean another tested model, a queue for later processing or temporary human review. Returning to the retired model will no longer restore the service.

Give the migration a clear owner

The work can span application code, business rules, evaluation data and deployment, which makes it easy to leave between the product team and whoever manages the AI account.

Blocshop's AI integration services support companies adding and maintaining AI capabilities within existing applications. Senior developers can take ownership of a defined integration, build its evaluation coverage, update the surrounding code and carry the change through release.

If replacing an AI model is competing with committed product work, talk to Blocshop about the affected workflows and the development capacity needed to maintain them.