如何重构Doctrine迁移文件且不破坏现有客户端数据库？求标准方案

我有一个使用Doctrine migrations的应用，该应用是一个代码库，用于管理多个业务方，每个业务方在独立环境中使用相同的代码实例，仅配置不同。

开发团队曾犯的一个错误是将核心迁移文件放在客户文件夹中。即每个新应用都需要放入迁移文件或执行migration:diff才能启动，这既低效又容易造成混乱。

我更希望将核心迁移纳入核心代码（因其极少变更），而自定义迁移放在客户端应用侧。

• 将所有核心结构迁移文件移至核心代码库
• 在客户端迁移文件夹中仅保留一个用于插入自定义数据的自定义迁移文件

我面临的核心问题是如何在不破坏现有客户端数据库的前提下重新组织迁移文件。

我想到了两种解决方案：

• 添加空白迁移文件作为目标新迁移的占位符
• 提交至代码仓库并部署到各环境
• 执行这些空白迁移（无实际变更），migrations表会标记它们已执行
• 将空白迁移替换为实际代码，清空其他迁移文件，提交并部署
• 最后删除无用的迁移文件及数据库中对应的迁移记录

• 修改数据库中迁移记录的存储位置
• 移除所有迁移文件，添加目标新迁移的空白文件
• 提交至代码仓库，执行这些空白迁移并在新表中记录已执行状态
• 添加实际迁移代码

完成后，新应用将使用更新后的迁移文件，旧应用也会适配新的迁移文件...

我是否在重复造轮子？是否有标准的实现方案？我肯定不是第一个遇到该问题的人。

内容的提问来源于stack exchange，提问作者HappyCoder