我在生产中运行了几个django-cms 2.4.3 (django 1.5.5)应用程序。我正在升级到Django -cms 3.1.1 (Django 1.8/python2.7)。我可以在没有问题的情况下启动并运行测试环境。但是，导入我现有的数据一直是个问题。我试过了:
- 'python management .py dumpdata ' . dump。
- 'python manage.py loaddata -ignorenonexistent dump。
结果是一系列已经存在的表，违反null约束，列不存在，等等
然后我尝试直接从postgresql导出(作为备份)并恢复到开发安装。运行python manage.py迁移。获得一系列类似于上面的额外错误。使用migrate——fake-initial和——fake来运行迁移。问题是许多页面(以cms_page为例)更改了3中的字段。X从2.4。Migrate只会查看迁移中的变化，表中的差异。添加了一些字段，删除了一些字段。我查看了cms_page迁移0001文件。它创建带有额外列的页表。迁移0003添加了更多字段并删除了一些字段。这样的例子不胜枚举。
我已经花了三天多的时间来迁移我现有的数据。我甚至开始用django-cms 3.0放一些插件自动将我的开发环境升级到3.1(不，我没有包括pip install -upgrade)。简直令人沮丧。
我甚至开始手动更新数据库表。表约束使得这几乎不可能。现在我正在考虑完全重写django-cms迁移。我是否忽略了一些可以使数据迁移更容易的东西?也许继续使用django-cms 2.4并将django升级到受支持的版本?
除非我误解了你在做什么，否则我认为你这样做是不对的。
您应该不会遇到迁移问题;它们是专门为使您正在做的事情(跨数据库更改升级)更容易而设计的。
如果你发现自己手动操作数据库表，你做错了，只会让事情变得非常困难。
应该怎么做:
1)复制现有的生产2.4.3站点-代码，数据库和所有。不要碰生产站点本身的任何东西，如果它能工作的话。从现在开始，只做拷贝。
2)确保迁移确实是最新的。从你的描述听起来，他们可能不是。
对于迁移目录中的每个迁移，您应该在数据库中的迁移表中有一个条目。如果没有，但是您确定您的数据库与模型代码是最新的，那么您可以运行migrate --fake以将这些迁移标记为已运行。
(如果您使用syncdb创建了数据库，并且没有使用--fake运行迁移以将表标记为最新，那么您可能会发现自己处于这种位置，我怀疑这可能是问题的根源。)
如果你有一些表是最新的，而有些不是，并且在迁移表中哪些是最新的记录不准确，祝你好运;你的处境很混乱，你必须小心地走出困境。
3)一旦你的代码、数据库表和迁移历史都从同一页开始，并且彼此一致，那么再复制一份代码和数据库，然后从那里开始工作，这样你至少有一个安全的地方可以返回。
4)现在开始升级软件，尽可能一次升级一个组件，并运行"migrate"。使用django CMS的发布说明来帮助你了解哪些被修改了，哪些需要被修改，以及你需要采取的任何其他步骤。
检查每个组件迁移后是否一切正常。
5)你也需要升级Django;使用发布说明来确定在继续进行下一次Django CMS更新之前何时必须升级Django。