我在生产中运行了几个django-cms 2.4.3（django 1.5.5）应用程序。我正在升级到django-cms 3.1.1（Django 1.8 / python2.7）。我可以在没有问题的情况下启动并运行测试环境。但是，导入现有数据一直是个问题。我试过了：
结果是已经存在一系列表，违反了空约束，列不存在等等......
然后我尝试直接从postgresql导出（作为备份）并恢复到开发安装中。运行python manage.py迁移。获得一系列与上述类似的其他错误。运行使用migrate --fake-initial和--fake进行迁移。问题是许多页面（让我们关注cms_page作为例子）已经改变了3.x中的字段2.4。迁移只会查看迁移中的更改，即表中的差异。添加了一些字段，一些字段被删除。我查看了cms_page迁移0001文件。它创建带有额外列的页表。迁移0003会添加更多字段并丢弃一些字段。这个清单一直在继续。
我花了三天时间尝试迁移现有数据。我甚至开始用django-cms 3.0把一些插件自动升级到我的开发环境3.1（不，我没有包括pip install --upgrade）。简直令人沮丧。
我甚至开始手动更新数据库表。表约束使得这几乎不可能。现在我正在考虑完全重写django-cms迁移。有什么我忽视的东西会使数据迁移变得更容易吗？也许留在django-cms 2.4并将django升级到支持的版本？
答案 0 :(得分：3)
您不应该遇到迁移问题;它们专门用于使您正在做的事情（跨数据库更改升级）更容易。
如果您发现自己手动操作数据库表，那么做错了并且只为自己制造了非常困难的事情。
应该做些什么：
1）制作现有生产2.4.3网站的副本 - 代码，数据库和所有。如果有效，请不要触摸生产现场本身的东西。从现在开始，只能在副本上工作。
2）确保迁移确实是最新的。从您的描述中可能听起来可能不是。
对于迁移目录中的每次迁移，您应该在数据库的迁移表中有一个条目。如果没有，但您确定数据库是最新的模型代码，则可以运行migrate --fake将这些迁移标记为运行。
（如果您使用syncdb创建数据库并且没有使用--fake运行迁移以将表标记为最新，您可能会发现自己处于这个位置，这就是我的意思怀疑可能是你问题的根源。）
如果您有一些最新的表，而某些表不是和不准确的记录，哪些是最新的迁移表，祝您好运;你是一个混乱的人，你必须小心翼翼地选择出路。
3）一旦您的代码，数据库表和迁移历史记录都在同一页面上唱歌并且彼此认同，请从代码和数据库中获取另一份副本并从中开始工作，这样您至少可以有一个安全的地方返回到。
4）现在开始升级软件，尽可能一次升级一个组件，然后运行``migrate`。使用django CMS release notes可以帮助您了解要更改的内容，需要更改的内容以及您需要采取的其他步骤。
在迁移每个组件后检查一切正常。
5）你也需要升级Django;使用发行说明确定何时必须升级Django，然后再继续下一个django CMS更新。