A migration playbook for voice agent model sunsets

On October 2, 2026, Hume posted a short changelog entry: its TTS and EVI APIs shut down on November 13, 2026 at 12:01 a.m. EST, and any data left in a Hume account is deleted after that. Three weeks later, Claude Sonnet 4.5 is scheduled for retirement on November 30. Six weeks after that, OpenAI's tts-1 and tts-1-hd disappear from the API on January 6, 2027, followed by the realtime and audio families on January 20. One tracker counts 192 dated model shutdowns across the major APIs between now and the end of June 2027.

For a voice agent in production, each one of those dates is a forced migration. The LLM, the STT, the TTS and the turn-taking layer each have their own retirement clock, and a terminated model ID returns an error at call time, between the STT and the TTS, where the caller hears nothing. This post is the pm playbook: how to meet a sunset date without rolling the dice on a Tuesday.

Why voice sunsets hurt more than text LLM sunsets

A text app that swaps GPT-4o for GPT-4.1 has one thing to verify: are the answers still correct and in the right shape. A voice agent has three or four moving parts, and each one of them has its own failure modes.

• A TTS swap changes prosody, pronunciation, how numbers and alphanumerics are read, how SSML pauses render, and how quickly the first audio chunk arrives. The caller hears all of it.
• An STT swap changes word error rate on your specific vocabulary, how aggressively partials are returned, and how diarisation and endpointing behave. Everything downstream, the LLM prompt, the tool arguments, the barge-in logic, feeds on the transcript.
• An LLM swap changes tool-calling schemas, system prompt handling, refusal behavior, and the number of tokens before first speakable chunk. It changes latency more than most teams measure.
• A realtime / speech-to-speech swap collapses several of those into one model and changes all of them at once. OpenAI's January 20 retirement of the original realtime and audio families is one of these.

The sunset problem is not "pick a replacement from a comparison chart." It is "prove the replacement will not regress any conversation you care about, before the day the old model stops answering."

The inventory nobody has

The first thing to do when a sunset notice drops is answer a question most voice teams cannot answer in an hour: which of our agents call this model, with which model ID, in which environment. The sensible version of that inventory lists, for every agent in production and in staging:

• Provider and exact model ID for the LLM
• Provider and exact model ID for the STT
• Provider, model and voice ID for the TTS
• Any realtime or speech-to-speech model that collapses the above
• The orchestration platform (Vapi, Retell, LiveKit, Pipecat, Bland) and the configured defaults it inherits from
• Any dormant test agents still holding live keys

Convo360's deprecation playbook makes the same point in blunter form: list every agent, model and voice, including the dormant ones, and subscribe to each provider's deprecations page rather than its blog. Retirement dates are published separately from release announcements, and the blog is the wrong feed for the information your incident calendar depends on.

Two patterns that pay for themselves immediately:

• One place where every model ID lives. A spreadsheet is fine. Agent, environment, layer, provider, model ID, voice ID, owner, deprecation link. Update it on every launch, not when the fire starts.
• A second provider key per layer, pre-configured and tested quarterly. The convo360 writeup frames it as a dropdown change rather than a migration; the point is that the credential, the quota and the integration surface are already real when you need them.

Set the internal deadline, not the vendor's

The vendor publishes an EOL date. Your date is earlier. SoluLab's guide to deprecation planning argues for an internal deadline 30 to 60 days ahead of the provider's cutoff so testing and rollback are not happening the week the old model disappears. For a voice agent I would push the near end of that: 30 days is barely enough when you have to re-record a reference voice, re-tune SSML, and re-measure latency.

Treat the internal date as the launch date. Everything that follows is scoped to it:

1. The replacement model (or models, if more than one layer is affected) is pinned.
2. Acceptance criteria are written down. Not "sounds about the same." Specific thresholds for latency to first audio, interruption handling, pronunciation of your domain nouns, tool-call accuracy, and spoken-number readback.
3. The sim suite that will decide pass or fail is agreed between product, QA and engineering.
4. The production replay set is selected: a bounded window of recent real calls that cover your most common and most sensitive scenarios.
5. A rollback contract is written: how traffic flips back, how fast, and who signs off.

Step 2 is the one that gets skipped. The sunset migration is not the time to discover the team disagrees on how good is good enough. Pin acceptance criteria before you look at a single call on the new model.

The sim suite is the gate

The migration cannot be verified from a transcript. Prosody, pacing, barge-in and interruption behavior, pronunciation on alphanumerics and prices, how the agent sounds when the caller is frustrated: none of that lives in text. You need to make the agent take real calls, on real phone infrastructure, with the full stack wired up to the new model.

That is simulation testing. Personas call the agent, each one with a voice, an accent, a speech pace, an emotional register and a background-noise profile. Scenarios drive the conversation (the ten you most care about, plus the five you most worry about). Audio-native metrics score what actually came out of the TTS, not what the LLM meant to say.

A sim suite of 20 to 50 scenarios, run as a single job against the new model, produces the artifact the migration decision actually needs: a per-scenario pass/fail, scored on the same metrics you used to launch the agent in the first place. The ones that fail are the migration's punch list.

Roark is built for exactly this: it dials your agent over real PSTN or WebRTC, scores every call on 64+ built-in audio-native metrics plus any custom metrics your team cares about, and does it across 45 languages and accents. The orchestration integrations with Vapi, Retell, LiveKit, Pipecat, Bland, and ElevenLabs mean you can point the suite at a dev agent that already has the new model wired in and get the pass/fail back without rebuilding your test rig.

Production replay is how you catch the long tail

The sim suite catches regressions on scenarios you thought of. Production replay catches regressions on scenarios you did not. Capture the last 30 days of real calls (or whatever window is defensible under your retention and consent posture), replay them against the agent running on the replacement model, and score the deltas.

Replay is cheaper than it sounds. You already have the caller audio. You already have the ground truth of what the previous agent said and did. You are measuring, call by call, whether the new agent is at least as good: did it get to the same resolution, in the same time, without new dead air, without new interruptions, without new pronunciation errors on the names and numbers that showed up in the real traffic. Roark's production replay turns real production failures into repeatable regression tests that stay in your suite after the migration is done.

Two reasons replay matters more than the sim suite on a sunset:

• The vendors who publish migration guides describe behavior on average. Your users are not average. The names, the postal codes, the policy numbers, the accents, the hold music, the IVR prefixes: all of that lives in your traffic and not in the vendor's eval set.
• The failures that end up on the postmortem are almost always ones nobody wrote a scenario for. Replay is how you find them before the cutover, not after.

The rollback contract

Every migration ships with a rollback plan. For a voice agent, "revert the PR" is not a plan if the old model has been retired and the old key no longer answers. A workable rollback contract for a sunset migration has three parts.

• A tested fallback provider. The convo360 playbook recommends configuring a second provider key per layer and testing it quarterly with real conversations. For a sunset, that fallback is the thing you flip to if the primary replacement regresses.
• A staged rollout. Route a small slice of traffic to the new model, watch dashboards and issue-rate for a defined window, then expand. The Vijenex writeup frames it as a database-migration posture, not a config change, which is the right instinct.
• A pre-agreed abort condition. Issue rate above X per 100 calls, p95 latency to first audio above Y ms, pronunciation accuracy on domain nouns below Z. Written down in advance. Signed off by the on-call.

If any of those three are missing, the plan is not a rollback plan; it is a hope.

What the next six weeks actually look like

If you run a voice agent today, the next six weeks have at least three dated events that may touch your stack: Hume EVI/TTS on November 13, Claude Sonnet 4.5 on November 30, and Gemini TTS and Live previews on November 17. The pattern repeats in January with the OpenAI retirements. The playbook does not change:

1. Inventory. Every agent, every model ID, every environment.
2. Pin the replacement the day the notice drops. Set your internal deadline 30 to 60 days early.
3. Write acceptance criteria before you look at the new model.
4. Run the sim suite over real phone calls, on personas and scenarios that match your traffic.
5. Replay recent production calls against the new agent and score the deltas.
6. Flip traffic in stages against a pre-agreed abort condition, with a fallback provider live.
7. Fold the regressions you found into the suite so the next sunset is cheaper.

The teams that treat model sunsets as a scheduled operational cadence, rather than as an emergency, are the ones who are still shipping new features in the week around the cutover. The teams that treat each one as a surprise are the ones writing the postmortem.

Simulation and replay are what make the difference. Roark exists because that gap, between knowing your voice agent will survive the migration and hoping it will, is a product, not a process.