Our big move to Django 3.2 has been blocked largely due the

oauth2_provider app. In Review Board 4, we switched this from our

in-house evolutions to the official migrations, with the belief that

that would be the better upgrade path going forward.
Unfortunately, at some point, that project reset their baseline

migrations, meaning that it was no longer possible to upgrade the app

without just starting over on the schema or doing some manual

workarounds. This is not an option for us.
Work was explored on giving Django Evolution the ability to override

migrations, and then on undoing a MoveToMigrations mutation. In the

end, the best solution was just to give our own upgrade code a

pre-upgrade step of modifying the stored evolution and migration state,

undoing the MoveToMigrations ourselves, and then overriding the

evolutions used for this app.
This is now done in a new reviewboard.upgrade module, which has

pre-upgrade and post-upgrade steps that can be applied by both

manage.py and rb-site upgrade.
The pre-upgrade step deletes the migration and evolution history for

oauth2_provider and modifies the stored signature. That then allows

our custom evolutions to apply on top of it. If this is a completely new

install, none of this kicks in, but Django Evolution will proceed with

the standard evolution process for creating the models for the app,

marking those evolutions as applied and setting us up for future

evolutions to this app down the road.
There's also a fix for the Profile model, which lacked evolutions for

one of the changes made for 5.0.

Tested upgrading from 3.0 and from 4.0 to 5.0 on SQLite.
Tested a brand new install of 5.0 on SQLite.
Tests are still pending for earlier versions of Review Board (which

are failing, but are unrelated to this, and likely regressions in

Django Evolution) and for MySQL and Postgres databases.