Doctrine Migration Rollback vs Content Versioning: Reverting a Sulu Content Type Schema Change

In Sulu, changing a content type definition modifies both the persistent database schema and the content model, yet the platform provides two separate recovery mechanisms that operate at different layers. A Doctrine migration down-step can revert the physical schema, while Sulu's content staging feature restores prior content element states without altering table structures. The unresolved decision is which mechanism offers a safer rollback when a content type change has already been deployed and existing content references are present.

The core trade-off is that a Doctrine migration rollback may fail if foreign-key constraints or dependent content records prevent the down-step, whereas restoring a content version preserves the data but leaves the database schema potentially out of sync with the original content type definition. Neither approach automatically coordinates both the structural and content-model reversion.

Which documented rollback path minimizes the risk of data loss or schema inconsistency when reverting a content type change in a Sulu application? Does the content staging feature track schema-level metadata in a way that makes it suitable for structural rollback, or is it strictly limited to content state restoration? What verification is required to confirm that the database schema and content model are aligned after choosing either rollback strategy?