Keep schema changes understandable
Consolidate development history without rewriting production history.
Inspect the canonical schema first
Before changing a database, inspect its actual schema: tables, columns, constraints, relationships, indexes, grants and policies. Compare the desired change with that state. Avoid repeatedly adding, renaming and removing columns without a plan.
A baseline is for a fresh database
The V1 implementation can construct a baseline from supported schema objects for a fresh production database. It preserves supported security metadata and refuses unsupported objects instead of silently dropping them. It does not copy development users or data.
That is how a long development sequence can become one understandable starting schema. It is not permission to squash migrations already applied to a live database.
After the first deployment
Applied migrations have immutable journal identifiers. Later publications check for schema drift and support additive, journaled changes. Destructive changes and data migrations need a separately reviewed path. A failed build must not apply production migrations.
For example, adding an optional customer note can be an additive change. Renaming or deleting a column with customer data needs an explicit migration and recovery plan. Restoring a source version does not undo a database migration.
Demo this honestly
In an isolated test app, add a nullable field, publish, and confirm existing records survive. Try a destructive change and confirm publication refuses it. Verify the deployed schema and migration journal, not only the UI. These real-provider checks are part of the managed hosting rollout.