尽管Flyway支持回滚（仅作为商业功能），但不鼓励使用它：
https://flywaydb.org/documentation/command/undo
尽管撤消迁移的想法很好，但不幸的是，有时它在实践中会崩溃。一旦您进行了破坏性的更改（删除，删除，截断……），便开始遇到麻烦。即使不这样做，您最终也将创建用于还原备份的自制替代方法，这些替代方法也需要进行适当的测试。
撤消迁移假定整个迁移成功，现在应该撤消。对于没有DDL事务的数据库，如果版本迁移失败，这将无济于事。为什么？迁移随时可能失败。如果您有10条语句，则第1，第5，第7或第10条可能会失败。根本没有事先知道的方法。相反，撤消迁移被编写为撤消整个版本的迁移，在这种情况下将无济于事。
我们发现更可取的另一种方法是保持数据库与当前在生产环境中部署的所有版本的代码之间的向后兼容性。这样，失败的迁移就不会成为灾难。该应用程序的旧版本仍与数据库兼容，因此您可以简单地回滚应用程序代码，进行调查并采取纠正措施。
这应该辅之以适当的，经过良好测试的备份和还原策略。它独立于数据库结构，并且一旦经过测试并证明其可以工作，任何迁移脚本都无法破坏它。为了获得最佳性能，并且在基础架构支持的情况下，我们建议使用基础存储解决方案的快照技术。特别是对于较大的数据量，这可能比传统的备份和还原快几个数量级。
