...

1. Read the release notes again.
2. Upgrade Django in the appropriate requirements file.
3. Run makemigrations to generate any new migrations for Django-maintained tables (e.g. group/user tables).
   1. If there are migrations that affect tables with a large number of rows (e.g. user tables), talk to DevOps to determine a release plan! Depending on the change, we may opt to fake the migration in production.
   2. If you do not know how many rows are in an affected table, talk to DevOps to get help finding this information! (Admitting you don't know before the release is very much preferred to doing so once the service goes down!)
4. Loadtest the new changes. Ideally performance should improve or remain the same. More importantly, however, we want to execute the code in an environment with production-like data scale.
5. Update the Open edX release notes at Open edX Release Planning. Open source maintainers will need to run similar, if not the same, processes we run to upgrade. Update the release notes informing them of the upgrade and anything to be weary of (e.g. migrations affecting large tables).
6. Release the Django upgrade by itself. If it breaks, we know exactly what to revert to fix it.

Post-flight

Just because the build pipeline is green doesn't mean you're done!

...