Gemini’s model retirement needs a real migration

Google’s November 2 release notes say Gemini 2.5 Pro and Gemini 2.5 Flash are deprecated and no longer selectable in Google AI Studio. From December 1, 2026, requests to gemini-2.5-pro will route to gemini-3.8-flash, while gemini-2.5-flash requests will route to gemini-3.5-flash-lite. Billing will follow the replacement model. These are the routes specified in Google’s release notes, checked on November 4.

The same notice flags breaking changes involving function calls, thought signatures, thinking configuration, sampling parameters, and prefilled turns. Updating a model string is therefore only one part of the work. Automatic routing can preserve an endpoint’s availability without preserving every assumption made by the application around it.

Inventory every place the model is selected

Start with a list of workloads, not a search-and-replace operation. A model name can appear in application code, configuration files, scheduled jobs, evaluation scripts, or a third-party workflow tool. Record the owner, traffic pattern, expected output, and failure consequence for each workload.

Give unattended jobs special attention. A monthly document-processing task may not run during an ordinary deployment check. If it has an implicit model dependency, the first visible failure could arrive after the migration deadline. Add a representative dry run to the migration plan rather than waiting for its next scheduled execution.

Write down the contract your application expects

An AI integration usually has a contract beyond valid JSON. A support classifier might need a fixed set of categories, a permitted confidence format, and a refusal path for missing information. A coding assistant might need valid tool arguments and a rule that changes are proposed before they are applied.

Create a compact contract for each workload. Describe mandatory fields, forbidden actions, acceptable uncertainty, and the point at which a human takes over. This document gives reviewers something more precise to evaluate than whether the new output “looks better.”

Test transitions, not only individual answers

A single successful prompt does not exercise a multi-turn integration. Include a first request, a tool call, a tool response, a follow-up correction, and an interrupted run. Inspect the actual request and response structures at each boundary. When an SDK manages part of that exchange, verify behavior using the SDK version you intend to deploy.

Use sanitized examples from real workload categories. Include ordinary tasks, ambiguous requests, long inputs, and cases where the correct behavior is to stop and ask for clarification. Preserve a small set for final acceptance so repeated prompt adjustments do not merely optimize for familiar examples.

Separate quality, latency, and spending

These dimensions can move in different directions. A new model may produce a more useful answer while generating more output, or finish an individual turn quickly while needing additional turns. Measure complete tasks and their retries. Do not infer a cheaper workflow from a model name or a shorter first response.

A practical comparison sheet can contain task identifier, accepted outcome, tool errors, elapsed time, input usage, output usage, and reviewer notes. Use current provider pricing for the cost calculation. Keep the raw usage alongside the computed cost so a later pricing change does not erase the meaning of the experiment.

Plan a rollback that remains available

Before the deadline, a previous model may provide a useful comparison. After a provider retires it, that old identifier may no longer be an escape hatch. Document an alternative that can actually operate after the cutoff: another supported model, a reduced feature set, or a manual queue for important requests.

Deploy the new route to a controlled portion of the workload, monitor the contract checks, and expand only when the observed behavior is acceptable. For external actions, keep review boundaries intact during the transition. A model replacement should not silently broaden what the agent is authorized to do.

The calendar is the immediate trigger, but the lasting benefit is an integration that knows its own assumptions. A named owner, a reproducible test set, and a viable fallback make the next model retirement a managed change instead of an emergency.