Who performs a migration, and who leaves it to you

One platform states outright that migration will not happen automatically. One application states the opposite for its own tiers: a withdrawn tier falls back on its own, priced as shown. Everywhere else the work of moving belongs to the customer. From 5 source pages, read 2026-09-12 to 2026-10-13; no maker pays to be listed.

Fig. 1 Filled where the vendor has announced something in that column, hollow where it has not.

What each entry says about who performs the move. Recorded 2026-10-13.
Entry	What is published	Detail
Amazon Bedrock	Migration will not happen automatically	Stated plainly on the lifecycle page
Microsoft Foundry	Not stated, and a version is named in the row	A deployment has to be edited by somebody
SceneMixer	A withdrawn tier falls back to the episode's last-used tier or the default	The price shown is the tier that runs
invideo AI	Nothing published; six makers are aggregated	Each maker decides for its own line
Every other entry	Nothing published	No statement in either direction

Inclusion rule. Filled from a published sentence about who migrates a customer. A migration tool documented elsewhere in a product does not fill a cell in this register. Order. The entry stating it first, then the rest.

1Saying it is more useful than implying it

Most pages here have nothing about migration, which leaves a reader free to imagine that a platform of that size handles it. One sentence closes that door and converts an assumption into a task.

A team that has read it knows the migration is on their plan and can size it while a model is still active, rather than during a legacy window with a fortnight of slack.

2Explicit versions make the work findable

Where a deployment or a request names a version, a customer can audit which of their own systems is affected. Where a purchase names a tier, they cannot, and the work starts with guessing.

That is why the entries with the most detailed schedules also require a version to be named. The two are one design decision seen from two sides.

Fig. 2 One application publishes a fallback for work in progress: the episode's last-used tier while it is listed, else the default, at the price shown.

3For applications the move may not be available at all

An application that replaces the model behind a tier performs a migration for its customers without asking, which is the opposite problem: the move happens and nobody chose it.

One entry publishes the rule it follows when that happens: work in progress falls back to the episode's last-used tier or the default, and the price on the button names the tier that will run. Whether a model behind a named tier is updated in place is still unpublished everywhere, and the reproducibility term covers that silence.

Whether the platform moves you across
Migration will not happen automaticallyAmazon Bedrock, model lifecycle / recorded 2026-09-22
sora-2 version 2025-10-06
15 July 2026retirement date, replaced by sora-2 version 2025-12-08Microsoft Foundry, retirement schedule / recorded 2026-09-22
Notice before a tier changes
No notice period published (as of 2026-09-12)nothing publishedSceneMixer, price list / recorded 2026-09-12
Work in progress when a tier goes
When a tier is withdrawn, text and image work falls back to the default tier and video to the tier the episode last used if it is still listed, otherwise the default; the price shown is the tier that will runSceneMixer, withdrawn tier guide / recorded 2026-10-13
Models carried
Google Veo 3.1, Sora 2, Kling AI, Wan AI, Pixverse AI and Hailuo AIaggregatedinvideo AI, model list / recorded 2026-09-12

4Sources

Dates come from the company that makes the model or the platform that serves it; menus come from the app, and both are linked on the calendar. Read 2026-10-13. What counts as a date is on sourcing. Nearby: Published states, Older generations, Quiet about the last version.