A shutdown date is a deadline for your workflow

When an AI video model is retired, the practical question is not what happened to the model but what in your work depends on it. OpenAI’s deprecations page says it notified developers on March 24, 2026 that the Videos API and the Sora 2 video generation models would be removed from the API on September 24, 2026.

That gave builders six months of notice and gives everyone else a date. If you have an automation, a template, or a client deliverable that calls the model, the date is a deadline for deciding what replaces it, and for finding out whether a replacement behaves the way you need.

This article offers a short check with four steps: inventory, capture, compare, and cutover. It is editorial synthesis, not a migration path from any provider. It is also different from moving a custom assistant to a new product, which the Custom GPT migration matrix covers. Here the provider has named no direct replacement, so the choice is yours.

Know what the sources say and what they leave open

OpenAI’s deprecations table lists six entries for September 24, 2026: the Videos API and five Sora 2 model names and snapshots. The recommended replacement column is empty for each of them. The video generation guide adds that no one-to-one replacement API exists.

The OpenAI pages cited here do not say what happens to videos or assets you generated through the API, or whether they can be exported after the date. Do not assume either way. If you hold finished videos, treat the copies you have as the ones that count.

ElevenLabs’ September 23 changelog describes its own side of the change: Sora 2 and Sora 2 Pro have been removed from its model picker and stop generating on September 24, existing Sora generations stay in a user’s history, and any flow or template with a Sora node must be switched to a different video model before it can run again. It names one option, Gemini Omni 1.1 Flash. Treat that as an example from one vendor, not as a recommendation or a proven match.

Inventory every place the model is used

Start with a simple list: each API call, template, automation node, and client project that uses the model, with the person who owns it. Include the quiet ones, such as a template a collaborator duplicated months ago or a scheduled job nobody has opened lately.

For a hypothetical example, imagine an independent educator who generates short background scenes for tutorials through an automation template and also keeps a few finished scenes in a client folder. The inventory would list the template, the scene library, and the client folder, because a swap affects each of them differently.

Mark what each item does, not only where it lives: does it create new scenes, extend old ones, or just store finished output? Each of those needs a different decision.

Capture what you still hold

Save the prompts, settings, reference images, and finished videos you can still access, and note where each copy is stored. Prompts and settings matter because you will want to rerun the same scenes on a different model, and finished videos matter because the sources do not say what remains available after the date.

Keep a short note with each saved item: what it was for, when it was made, and which project it belongs to. A prompt without that context is hard to reuse, and an unlabeled video is hard to match to a deliverable.

Do not treat capture as a promise that anything will be recoverable. It is a way to hold on to what you have, using the same discipline as the content archive restore drill: assume the original source may not be there when you need it.

Test a candidate on one reference scene

Pick one scene you know well, one where you can say what is good and what is wrong about the result. Rerun it on a candidate model and judge it against your own criteria: does it look right for the project, follow the instruction, and avoid problems you would have to fix by hand?

Do not judge it by how closely it matches the old model’s output. A different model will make different choices, and a close copy is not the goal. What matters is whether the result meets the standard of the work it will appear in.

Check the things a single scene will not show: cost, speed, how the model handles a series of scenes, and whether it fits your template or automation. The AI video production system article covers scene review, regeneration budgets, and visible creator judgment, which are the same checks applied to a new model.

Switch with a record, one workflow at a time

Change one workflow at a time, starting with the one that matters least. If a template breaks, you will know which change caused it. Note the date, the reason, the model you chose, and anything you had to adjust, so a collaborator can follow what happened.

Check that your disclosure and rights notes still fit. A different model may have different terms, and the way you describe AI-generated scenes should match what you actually used. The disclosure carryover matrix shows how to recheck what carries over when a piece changes.

A shutdown is a good moment to write down how your workflow depends on outside tools. A short inventory, a saved set of prompts, and a tested alternative will make the next retirement a smaller problem than this one.