Seedance 1.5 Pro has a published retirement date: November 11, 2026. If you use it through another video service, check that service's notice before planning another render. A model's final shutdown date and the date a platform stops offering new generations can differ.
ElevenLabs' September 23, 2026 changelog says ByteDance is retiring the model on that date, that it is no longer offered for new generations there, and that users should switch to a Seedance 2.0 model. This is an existing notice, reviewed on October 15, rather than a new model announcement today.
This article explains the notices and provides an original migration checklist. Seeora has not tested a cross-platform migration or measured replacement quality. The checklist is a way to organize your own validation, not a promise that changing a model preserves a shot.
AI-generated concept illustration made with Codex imagegen; not a platform screenshot or Seedance output.
What the date means on different platforms
NightCafe's official deprecation notice also identifies November 11 as its removal date. It says existing creations remain in the account, while new video creation with the model becomes unavailable after the cutoff. Until then, its notice says users can still select the model, which carries a departure label. NightCafe now defaults new Studio videos to PixVerse V6 and lists newer Seedance options among its alternatives.
These notices agree on the retirement date but describe different current availability. Do not treat a model disappearing from one picker as proof that every service has already removed it. Equally, an available picker today does not establish that a saved workflow will run after the deadline.
| Where you work | What to check now | Planning implication |
|---|---|---|
| ElevenLabs | Its changelog says new 1.5 Pro generations are no longer offered | Choose a supported replacement before another run |
| NightCafe | Its notice allows use until the November cutoff | Schedule replacement validation before that date |
| Another provider or an automated workflow | Read the provider's own availability and retirement notice | Do not assume identical access, settings, or history retention |
Preserve the recipe as well as the finished video
Before changing a saved project, make a migration record for each important shot. Keep the original prompt, source images, selected opening and closing frames, requested duration, aspect ratio, audio choice, and the service where you generated it. Save a copy of the finished render as your visual reference.
Also record what makes that render acceptable. “Good character consistency” is difficult to compare. “The red coat remains visible through the turn, the camera ends at the doorway, and the last frame leaves room for the title” gives you observable criteria. Note whether the shot must fit an existing edit or can change length.
For a series, identify the shots that share a face, prop, room, or voice. Validate those as a group before replacing individual clips. A replacement that looks attractive alone can still create a mismatch when placed between two retained shots.
Choose the replacement around the inputs you need
Start with the service's documented replacement. ElevenLabs directs affected users toward Seedance 2.0; its current Image & Video documentation describes text, frame, image, video, and audio inputs for that family. It also describes different limits for individual variants and regional restrictions, including United States unavailability for its Seedance models. Availability should be confirmed in your own account.
Do not pick solely by version number. Build a small requirements sheet: do you need a specific final frame, a reference-driven character, generated sound, or a fixed delivery shape? Match those needs to the selected variant's current documentation and controls. The settings exposed by one hosting service are not automatically the settings exposed by another.
For background on reference-driven generation, see Seedance 2.0. If a project depends on music, separate the task of guiding generated performance from preserving an exact final recording; the audio-reference explanation discusses that distinction.
Validate one representative shot before a batch
Duplicate a working project or prepare a separate test record. Keep the old render unchanged. Begin with a short shot that includes the dependency most likely to fail: a final-frame transition, a face turning away, a spoken phrase, or a prop crossing the frame. An easy landscape will not reveal whether a dialogue workflow still works.
Use the original creative brief as your starting point, then adapt only the inputs required by the replacement. Write down each change. If the service rejects a setting, check the supported controls rather than repeatedly resubmitting the old configuration. Record accepted parameters alongside the new render so the result can be reviewed later.
Review the replacement beside the original and inside the actual timeline. Check identity, action order, framing, audio timing, and the cut into the following shot. If it fails, decide whether to revise the prompt, split the shot, change the reference arrangement, or choose another supported model. This is a proposed validation process; no comparative success rate is claimed here.
Update saved workflows and cost assumptions
For automation, inventory every place the retired model is selected: saved presets, scheduled jobs, templates, and reusable generation steps. Replace one instance, run a small end-to-end check, and confirm that downstream editing or delivery receives the expected file. Keep a record of which workflows have actually passed; editing a selection is not proof of a successful render.
Recheck the cost shown by your provider before scaling up. Compare the expense of an accepted shot, including retries and any finishing work, rather than assuming the old budget transfers. A nominally cheaper generation can require more attempts for your specific scene.
Your next action is straightforward: check the notice for the platform you use, preserve one important shot's full recipe, and validate its replacement before updating the rest. Keep the retirement date in your production plan, while treating each provider's current availability as its own fact.