Plan a Django upgrade in testable steps

Create a baseline before choosing the jump

Record Django, Python, database driver and third-party package versions. List the critical flows and existing tests. For a very old interpreter, finding a reproducible safe baseline can itself be scoped work. Do not run the legacy application with real secrets or customer data just to see whether it boots.

• Keep the current dependency constraints and lock or requirements files.
• Identify abandoned packages and custom middleware.
• Name the intended maintained target and verify current support separately.

Use release boundaries as checkpoints

Read the release notes and deprecation timeline for every release crossed. Django says incremental feature-release upgrades are usually easier, using the latest patch at each step. Each checkpoint should run the same business tests; a framework import alone does not establish that login, forms or writes still work.

• Enable deprecation warnings in a disposable test environment.
• Resolve project warnings and assess third-party warnings separately.
• Select the intended version explicitly instead of using an unconstrained upgrade command.

Treat database and cache changes deliberately

Review schema migrations, application writes and the required restore route. A code revert may not reverse schema or data changes. Django also notes that cached pickled objects can be incompatible across versions; define an authorised cache handling step rather than assuming old values remain usable.

• Test with synthetic fixtures and expected row-level results.
• Record migration order, restrictions and rollback limitations.
• Keep uploaded media in the backup inventory, not only database tables.

What an upgrade handover should prove

The target stack should run the agreed login, administrative and business flows with a reviewed dependency change and explicit deployment limits. Keep the intermediate results, final tests and restore evidence together. Production publication, secret configuration and any irreversible migration require named customer approval; this planning guide is not permission to deploy.