LLMSwaps

Which model each app runs today, and when it last changed

Who performs a migration, and who leaves it to you

Nobody moves you. One platform states outright that migration will not happen automatically, and no entry anywhere in this register states the opposite. One dated row names where to go; the work of getting there belongs to the customer in every case. As of 2026-09-12.

What has been announced, entry by entryFilled where the vendor has announced something in that column, hollow where it has not.What has been announced, entry by entryWhat is publishedAmazon BedrockAmazon Bedrock — What is published: Migration will not happen automaticallyMicrosoft FoundryMicrosoft Foundry — What is published: Not stated, and a version is named in the rowSceneMixerSceneMixer — What is published: Nothing published about a tier changing modelinvideo AIinvideo AI — What is published: Nothing published; six makers are aggregatedEvery other entryEvery other entry — What is published: Nothing published
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-09-12.
EntryWhat is publishedDetail
Amazon BedrockMigration will not happen automaticallyStated plainly on the lifecycle page
Microsoft FoundryNot stated, and a version is named in the rowA deployment has to be edited by somebody
SceneMixerNothing published about a tier changing modelNor whether a project keeps its engine
invideo AINothing published; six makers are aggregatedEach maker decides for its own line
Every other entryNothing publishedNo 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.

Two opposite problems, and nobody in the middleOn a platform the move is the customer's work and no successor is named. On an application the move can happen without anybody choosing, because the model behind a tier is replaced. Neither arrangement leaves a production in control.Who decides when your work changes engine?You name a versionYou doAnd migration will not happenautomatically, as one page states.You bought a tierThe seller doesThe engine behind it can be replaced withthe interface unchanged.Explicit versions make the work findable; a tier name makes it invisible
Fig. 2 No entry here publishes anything about whether a project in progress keeps the model it started on.

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.

No entry in this register publishes anything about whether a project in progress keeps the model it started on. The reproducibility term covers that silence.

4Sources

Dates come from the vendor that makes the model; menus come from the app, and both are linked on the calendar. Read 2026-09-12. What counts as a date is on sourcing. Nearby: Published states, Older generations, Quiet about the last version.