我应该尝试实际升级现有的应用程序，还是只从头开始重写它，保存我能做的哪些工作(模板等)？

解决方案

升级。对我来说，这非常简单：将__str __()更改为__unicode __()，编写基本的admin.py并完成。只需在1.0上开始运行应用程序，对其进行测试，当遇到错误时，请使用与向后不兼容的更改有关的文档，以了解如何解决该问题。

尽管这取决于工作，但是大多数应用程序都应该能够升级然后修复所有故障。根据我的经验，升级后必须修复的主要问题是

• 对一些带有模型的时髦内容的更改，例如跟随外键的语法。
• 一小组模板更改，最值得注意的是自动转义。
• 任何取决于Django内部结构的东西。除非我们正在做一些事情，例如动态修改Django内部结构，以对项目必需/方便的方式更改其行为，否则这不是问题。

总而言之，除非我们要做很多真正的怪异和/或者复杂的事情，否则简单的升级应该相对容易，并且只需要进行一些更改即可。

只需升级应用即可。从0.96到1.0的转换幅度很大，但就向后不兼容更改而言，我怀疑应用程序甚至有10％。

我在Django 1.0之前就处于干线状态，所以我的过渡是随着时间的推移，但是即使如此，我唯一需要更改的主要内容是newforms，newforms-admin，str()到unicode()以及maxlength到max_length

其他大多数变化是新功能或者后端重写或者其他东西，因为那些正在构建基本网站的人甚至都无法接近。

只有最简单的站点才易于升级。

如果站点碰巧是世界上非ASCII区域的站点，请期待真正的痛苦(阅读：美国和英国以外的任何地方)。 Django中最痛苦的更改是内部从字节串切换为unicode对象，现在我们必须找到使用字节串的所有位置并将其更改为unicode。最糟糕的情况是模板渲染，直到得到UnicodeError，我们才不会忘记更改一个变量。

其他值得注意的事情：机械手(旧形式)已经消失，除了用表格(新形式)重写所有零件外，我们别无选择。

如果情况如此，并且项目大于2-3个应用程序，那么在真正需要之前，我宁愿不进行升级。

我们通过一个多步骤的过程进行了升级，对此我感到非常满意。有问题的应用程序大约有100.000 LoC，并运行多个核心业务功能，并且与传统系统有很多接口。我们像这样工作：

• 更新到django 0.97-post unicode合并。解决所有unicode问题
• 将应用程序重构为可重用的应用程序，添加测试。这使我们在主应用程序/项目中获得了40.000 LoC
• 升级到django 0.97-post autoexcape合并。修复在3中创建的可重用应用程序中的自动转义。然后修复主应用程序中其余的自动转义问题。
• 升级到1.0。剩下的大部分是修复管理员的东西。

整个过程耗时约6个月，我们在服务器上运行旧版生产分支，同时将另一个分支移植到1.0。在这样做的同时，我们还在向生产分支添加功能的地方。

最终的合并比预期的要少得多，并且四个编码员花费了大约一周的时间进行合并，审查，测试和修复。然后我们推出了，大约一个星期前就被以前意想不到的错误所困扰。

总而言之，我对结果非常满意。现在，我们有了一个更好的代码库，可以进行进一步的开发。