A lot of this is still work in progress, but the key idea is that the framework and the cloud environment have to work together for this, because what you have in the current version of the code has to be compared with what the environment has before the deployment.

We don't automatically generate migration code - there's a set of structured mapping / guardrails, so for example if you add a new field without marking it as optional, you should get a warning/error when deploying it on an environment with existing data that has old records without that field set.

Modelence also has built-in support for user-defined migration scripts for more complex cases, but in these simpler cases we will be adding easy mappings with existing patterns, for example "set the field to X as the default value for all existing data".

Our focus here is the guardrails rather than the migration itself - LLMs today (especially Opus) are smart enough to figure out how to do the migration, but the guardrails make sure they don't miss it under any circumstances.