How to upgrade django project multiple versions (1.8 to 1.11+)?

Question

I'm upgrading an old project running on Django 1.8 to at least Django 1.11 for LTS. I've heard upgrading a django project multiple versions can be difficult and frustrating. I haven't done this, so my question; is it better to do an upgrade per version, 1.8 -> 1.9 -> 1.10 -> 1.11. Or do you advice me to upgrade straightaway to 1.11 from 1.8. Please leave your best thoughts on this and other things I need to keep in mind while upgrading.

Thanks in advance

Lxx

It would be easier to upgrade per each version – Gosney

I did exactly this today, no issues. Direct way from 1.8 to 1.11 (but I had the possibility to take a snapshot before I started). If you fear it...do every single step. – Fiesta

First, make sure your project runs in Django 1.8 without deprecation warnings. In theory, if it does then it should work with Django 1.11. In practice, you might find that you have to upgrade other apps and make changes because of that. – Adenectomy

Indeed, the apps that are installed on the project will give most problems while upgrading I think. – Lxx

Answer 1

The upgrade can be difficult, depends on your situation.

First, check the changelog for every version. The goal here is to understand if there is a major change that can affect your code. For example, the on_delete parameter in the foreign field models was optional, now is mandatory.

If you spot something, just update your code. What can really make the differences are the presence of tests. When we move from python2 to python3 and django 1.7 to 1.11 the tests were our insurance.

We just start to upgrade our code to a different branch using the virtualenv with the new python and new django and just fixing, testing and then merging in develop. If you don't have tests maybe is the right time to write some of them.

I would not suggest you jump directly to django 2.0. Again, if you have tests you can update gradually and then check the deprecation warnings. Those are very helpful to prepare your code for the next version.

Update

During the process, we check our requirements and revise every package we had in our system to verify the compatibility. We clean up a little bit removing some packages and update some others. Again, if you have tests you have your insurance :-)

Conclusion

• Check the changelogs
• Use a separate branch

Then:

1. Update gradually ( e.g. from 1.7 to 1.8)
2. (write and) Run tests
3. Update your code/packages
4. Run tests
5. If all it's ok then merge back in develop
6. branch again and go back to 1

Linter

Thank you for your clear explanation. Especially the updating packages will be difficult, so I like your suggested approach. – Lxx

@karim I'm facing the on_delete problem. BUT, my main problem is I made the change in the model and include the on_delete property to the ForeignKey field. But, it is not recognized as migration related so my migrations haven't changed when I invoke makemigrations. What should I do? change the migration where I include that and modify that? it won't affect the older databases for example. Any suggestion? How can I avoid this problem? Regards – Rafter

Well, based on Django documentation: docs.djangoproject.com/en/2.1/releases/1.9/… You should: ``` Update models and existing migrations to explicitly set the argument. Since the default is models.CASCADE, add on_delete=models.CASCADE to all ForeignKey and OneToOneFields that don’t use a different option. You can also pass it as the second positional argument if you don’t care about compatibility with older versions of Django. ``` So, yes, you should updated previous migrations! – Rafter

Answer 2

Is not that far away from 1.8 to 1.11. I have updated versions like this before and I rarely ever had a problem. Usuary the problems that I had wasn't related to Django at all most of the time was because some libraries that were being used in the project that required to be updated as well as we update Django

Factor