Staying current is cheaper than catching up
Django has a defined release and support cycle. An application several versions behind cannot be upgraded in one step, because every third-party package has also moved.
Upgrading annually is a few days. Upgrading after four years is a project, and it is one nobody has budgeted for.
The order
- Get the tests passing on the current version first
- Fix the deprecation warnings the current version reports
- Upgrade one major version, not several
- Update third-party packages that require it
- Run the full test suite and check manually
Deprecation warnings on the current version are the upgrade instructions for the next one. Clearing them first makes the upgrade largely uneventful.
Third-party packages are the usual obstacle
- Check each dependency supports the target version before starting
- An unmaintained package that does not is a decision point
- Replacing it may be part of the upgrade
- Fewer dependencies means easier upgrades, which is one more argument for restraint
Test on production-like data
| Test | Catches |
|---|---|
| Full test suite | Code-level breakage |
| Migrations on a production-sized copy | Long-running migrations |
| Manual check of key workflows | Behaviour changes tests miss |
| Performance comparison | Regressions |
| Third-party integrations | Package incompatibilities |
Plan it, do not wait for it
Put the upgrade in the plan annually, before support ends. Upgrading on a schedule is routine; upgrading because support ended is urgent and disruptive.
It is also considerably cheaper, which is the argument that usually gets it budgeted.