Export first, migrate second. When a model is deprecated the irreversible loss is platform-stored files, not access to the model — and the window for that closes on a date. Prompts don't transfer cleanly between models, saved references mostly do, and the thing that actually survives a deprecation is a pipeline where your finished work lives somewhere the vendor doesn't control.
Sora was a default choice in early 2026 and its API shuts down on 24 September. That's the timescale to plan against, and it's shorter than most production cycles.
What actually gets lost?
Three things, and only one of them is permanent.
Access to the model. Recoverable in the sense that another model exists. What you lose is a specific look and specific behaviour you'd built around.
Platform-stored files. This is the permanent one. When OpenAI discontinues Sora, data associated with Sora accounts is deleted after the cutoff dates. Files you'd already exported are unaffected.
Prompts that were tuned to that model. Not deleted, but not portable either. A prompt refined over dozens of iterations encodes assumptions about how one model interprets language, and those assumptions don't hold elsewhere.
The ordering matters because only the second is time-boxed. Everything else you can work on after the shutdown.
Access is replaceable. Your library isn't, and it has a deadline.
What transfers, and what doesn't?
Four asset types, and they behave very differently.
| Asset | Transfers? | What to do |
|---|---|---|
| Exported video files | Yes, entirely | Nothing, as long as you exported them. This is why export comes first |
| Original reference images and photos | Yes | Keep your own originals rather than relying on a platform's copies. They're model-agnostic |
| Saved references — actors, locations, styles | Mostly | Your library is workspace-level rather than model-level, so the handle and the asset survive a model change. Whether the same reference renders the same way on a different model is untested |
| Prompts | Partially | The description and structure transfer. The specific phrasing that made one model behave doesn't |
Source: Hexcoded product behaviour and general migration behaviour, checked September 2026. Specific portability varies by platform.
Where this falls short. "Partially" is doing real work in the last row. A prompt's shot description, blocking and identity block all survive. The stylistic phrasing you added because it happened to work is the part that stops working, and it's usually not labelled as such in your own prompt.
Why don't prompts transfer cleanly?
Because a tuned prompt is partly a description and partly an instruction to one specific interpreter.
The description part — who's in shot, where they are, what the light is doing, what happens — is about the world and it transfers to anything. The tuning part is the accumulated phrasing you added because a particular model responded to it, and that's a property of the model rather than the scene.
The practical move on migration: strip your prompts back to the description, generate on the new model, then re-tune from there. Carrying the old tuning across usually produces worse results than starting from a clean description, because you're fighting two interpreters at once.
What about your saved references?
Better news than most of this post, and worth knowing precisely.
Your reference library is workspace-level rather than tied to any model. Actors, locations, styles and elements you've saved with a handle stay saved. A model going away doesn't take your cast with it.
What isn't guaranteed is that the same reference produces the same result on a different model. The asset persists; how it renders is a separate question. Which is the argument for keeping your own original source files — the photograph you uploaded, the reference art you made — outside the platform. Those are the genuinely irreplaceable inputs.
What if the model doesn't go away, but you lose it?
A case nobody plans for, and it's more likely than a shutdown.
Model access can be plan-gated. Hexcoded's plan comparison shows the entry tier starting with a core model set, the next tier unlocking most models, and full access above that. So a downgrade removes models from your picker without any model being deprecated anywhere.
The practical consequence is the same as a deprecation and the notice period is your own billing cycle. If a series depends on one specific model, that dependency is worth knowing about before a plan change rather than after.
What does this mean mid-production?
A deprecation during a series is the hard case, because consistency is the thing at risk.
A model change mid-series is visible. Different models render faces, light and motion differently enough that episode 31 doesn't match episode 30, and viewers register it even when they can't name it.
Two workable approaches, and both cost something. Finish the season on the current model if the timeline allows, then switch at a season break where a shift in look is defensible. Or switch immediately and accept a visible seam, which is better than a seam appearing at an arbitrary point when the deadline arrives.
What doesn't work is switching gradually. A series that drifts across three models over ten episodes looks like a production problem rather than a choice.
How do you build so this hurts less?
Five habits. None costs anything at the time.
Export as you go, not at the end
Finished work leaves the platform when it's finished. Platform storage is convenience, not archive, and a deprecation converts convenience into a deadline.
Keep your own original inputs outside the platform
The photographs you uploaded, the reference art you made, the source files. Saved references survive a model change; your original inputs are what survives everything.
Write prompts in two parts
Description first, model-specific tuning clearly separated after it. On migration you keep the first half and rewrite the second, which is much faster than untangling a fused prompt.
Know which single model you'd be stuck without
If there's one, that's your exposure. Being able to name it is most of the mitigation — you'll notice its deprecation notice rather than reading about it later.
Check what your plan actually includes
Model access is tiered, so a downgrade can remove a model as effectively as a shutdown. Worth knowing before a billing decision rather than after.
How much notice do you actually get?
Enough, if you're watching. Not enough if you aren't.
Sora's discontinuation ran to months rather than weeks — the app and website closed on 26 April 2026, with the API shutting down on 24 September 2026, covering sora-2, sora-2-pro and the Videos API with no recommended replacement. That's a reasonable window, and it was announced rather than discovered.
The failure mode isn't short notice. It's not reading the notice, because deprecation announcements go to API changelogs and account emails rather than anywhere a creator looks daily.
The habit worth having: check the vendor's deprecation page for any model you depend on when you plan a season, not when you hear a rumour.
- Export first, migrate second. Platform-stored files are the only irreversible loss and they have a deadline
- Exported files and your own original inputs transfer entirely. Keep both outside the platform
- Saved references are workspace-level, so a model change doesn't take your cast with it. Whether they render the same is untested
- Prompts transfer partially. The description survives; the model-specific tuning doesn't
- On migration, strip prompts back to description and re-tune. Carrying old tuning across fights two interpreters at once
- Model access is plan-tiered, so a downgrade can remove a model without any deprecation
- Mid-production, put the seam at a season break. A seam you chose reads as a decision
- Never switch gradually across a series. Drifting through three models looks like a production problem
Export everything stored on the platform. Access to a model is replaceable and platform-stored files aren't — when a service is discontinued, associated data is typically deleted after the cutoff, while files you'd already exported are unaffected.
Partially. The description — who's in shot, blocking, light, action — transfers to anything. The specific phrasing you tuned because one model responded to it doesn't, because that's a property of the model rather than the scene.
The references do — your library is workspace-level rather than tied to a model, so saved actors, locations and styles remain with their handles. What isn't guaranteed is that the same reference renders the same way on a different model, which is why the original source files are worth keeping outside the platform.
Yes. Model access is plan-tiered — an entry plan starts with a core set and higher tiers unlock more — so a downgrade removes models from your picker with your own billing cycle as the notice period.
Model changes are visible — different models render faces, light and motion differently enough that consecutive episodes stop matching. Either finish the season on the current model if the timeline allows, or switch immediately and place the seam deliberately. Don't switch gradually.
Sora's ran to months — the app and website closed in April 2026 with the API following in September. The problem is rarely the length of notice; it's that announcements go to changelogs and account emails rather than anywhere creators look daily.
One roster, less exposure
Creative Studio runs 30+ models on one credit balance, so losing one is a shot-level decision rather than a migration. Your reference library is workspace-level, so your cast doesn't go with it.
Open Creative StudioMore on model capability, access and rights in Models.