移除Django中客户端特定数据迁移的方案是否可行？

方案合理性判断 #

你的方案整体是靠谱的，分场景看都没问题：

• 新客户那边：空迁移文件（只留壳子，没数据操作逻辑）完全不影响，Django只会标记它已执行，不会搞任何数据变更，安全得很。
• 初始客户那边：这些迁移早就跑完了，他们数据库里的django_migrations表已经有记录，就算你把迁移里的操作删了，后续部署时Django会认出来这迁移已经执行过，不会瞎搞，之前的数据也不会被回滚，完全不影响现有业务。

必须考量的几个要点 #

• 迁移依赖链不能断：得查清楚这些数据迁移有没有被后面的结构迁移或者其他迁移依赖。比如要是有个后续迁移用到了这个客户专属的数据（比如外键关联），那新客户跑迁移时肯定报错。一定要把所有迁移的依赖关系捋明白，确保删了数据操作后不会出问题。
• 别删迁移文件本身：要是直接把整个迁移文件删了，初始客户后续部署时，Django会觉得这个迁移从没执行过，又找不到文件，直接报错说迁移缺失。留着空文件才是对的，保证数据库里的迁移记录和代码库里的文件能对应上。
• 版本控制要注意：用Git的话，删数据操作的提交别影响到初始客户的代码拉取。最好单独开个分支做推广版本的修改，避免初始客户误拉到改了迁移的代码。
• 文档要跟上：更新项目里的迁移说明，把这些空迁移原本是干啥的（给初始客户插专属数据）写清楚，免得后面维护的人搞不懂为啥有一堆空文件。
• 一定要测试：在测试环境模拟新客户从0开始部署，跑一遍所有迁移，确认数据库结构和初始数据都正常；再模拟初始客户的部署流程，确保现有数据没变化，迁移也不会重复执行。

可选的替代方案 #

要是觉得空迁移看着别扭，也可以试试这个办法：

• 给推广版本生成全新的初始迁移：用python manage.py makemigrations --initial生成包含当前所有结构的新初始迁移，然后删掉原来的旧迁移（包括客户专属的）。但这个操作风险高，得确保初始客户的数据库已经是最新结构，还要用python manage.py migrate --fake把新初始迁移标记为已执行，不然会重新创建结构搞坏数据。所以还是你原来的方案更简单安全。

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