Ghost CLI migration rollback behavior after partial upgrade failure

Migration transaction boundaries

Ghost CLI upgrade applies database migrations per file in a transaction. If a later migration in the same upgrade run fails, earlier migrations in that batch remain applied. The migrations table records name, batch number and timestamp only, with no checksum or rollback SQL.

Recovery gap

ghost doctor can flag inconsistent migration state but provides no built-in rollback operation. Ghost 5.x backup creates a SQL dump before upgrade, yet the CLI does not orchestrate restoration. Custom migrations in core/server/data/migrations are treated identically to core migrations, leaving a partially migrated state with no CLI-assisted recovery path.

Open questions

• Is rollback intentionally unsupported by design for Ghost 5.x migrations?
• What is the intended operator responsibility when a migration fails mid-batch and no acceptable backup exists?
• Will a future release add migration checksums or a formal rollback boundary for a batch?