Thanks to both of you for the clear responses.
Also, I don’t mean to suggest more work for anyone. I’m only thinking of possibilities for reducing the downtime to the core workflow. 4-7 days feels like the end of the world. 
FYI, I feel a little awkward offering advice like this on a project on which I’m unlikely to be putting actual effort. Just know that I support this project, I believe you’ll do your best, and you have my full support (whether or not you take my suggestions). 
Yikes! Is there any indication of how this impacted contributions afterward?
Correct!
It’s a shame that we can’t disable issues temporarily.
Would it be possible to migrate the inactive issues into a different GH repo and then move the issues over to the CPython repo afterward (but just before migrating all the active ones)? IIRC, GH already has a public (UI) mechanism to move issues between repos. Or perhaps we’d need the fine folks at GitHub to do that part for us due to the scale and the race on creating new issues. Regardless, that’s an established workflow on GH so as a workaround it’s less likely to be fragile or problematic.
Agreed. That’s why I suggested marking those issues as read-only in BPO (if possible). Anyone that wants to re-open one of those issues could wait until the migration is over. This is worth it if it means the project-wide downtime is drastically reduced.
To be clear, I’m not saying we pre-migrate all closed issues. We would do it for closed issues that were closed more than 3(?) months ago and any open issue that hasn’t had any activity for 6(?) months. I’d call that “relatively inactive”. The actual thresholds would roughly match issues that are unlikely to having any activity during the start of the pre-migration to the end of the actual migration.
Yeah, it’s definitely worth avoiding that.