Nick, while you were out we've been exploring strategies to mitigate the risk associated with the downtime required by the migration script "20210405-update-datetime-columns.sql", as well as with the possibility that we might have to revert that migration (as happened with circulation.openebooks.us due to an old version of the Open eBooks mobile app in the Play Store).

1. Make a copy of the database prior to migration and fall back to the copy if we need to revert.
2. Defer the need for a migration by using SQLAlchemy trickery to convert datetimes between timezone-aware and timezone-naive as they leave and enter the database.
3. Change the way we alter the database schema so that a) reverting is fast, not slow, b) we may be able to do some of the migration without taking the site down. (Discussed below.)

IMO #2 is very risky. #3 is somewhat risky, and #1 will take a long time to set up. Take a look at each of these and let's decide how to proceed.