Upgrades and migrations

Deploy compatible core-server and core-app versions together. Back up the database before an upgrade and establish a rollback procedure for the deployment.

Startup migrations run under a database-wide advisory lock. Each migration commits its schema, data changes, and history together. If a migration fails, its transaction rolls back; earlier committed migrations remain applied. A later startup resumes the failed step after the problem is resolved.

Stop old server binaries before adopting the migration runner. The migration lock does not prevent an already-running old binary from using the database. Do not assume rolling upgrades are supported.

People and authentication migrations preserve established IDs. Conflicting email records can stop the migration instead of being silently merged. See People and Authentication Deployment.

Downgrading the binary alone after schema changes is unsupported; restore a matching database backup for rollback.

Workflow placeholder

Publish release-specific upgrade procedures

Add a compatibility matrix, preflight checks, backup verification, stop/upgrade/start commands, acceptance tests, rollback steps, and the supported source versions for each release. Confirm current database schema versions against the release.