# GitHub Issues Migration is coming soon **URL:** \ **Category:** Core Development\ **Created:** [February 18, 2022, 8:54pm UTC](https://discuss.python.org/t/github-issues-migration-is-coming-soon/13791 "2022-02-18T20:54:54Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![ezio-melotti](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@ezio-melotti](https://discuss.python.org/u/ezio-melotti)\ **Post date:** [February 19, 2022, 12:52am UTC](https://discuss.python.org/t/github-issues-migration-is-coming-soon/13791/8 "2022-02-19T00:52:42Z")
> [@eric.snow](#): > > 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. 😱 Your comment already led us to consider and discuss a couple of different approaches and optimizations. We will perform a full test migrations beforehand to get a more accurate time estimation, and then consider the trade-offs involved and decide whether to add optimizations or not. > [@eric.snow](#): > > Yikes! Is there any indication of how this impacted contributions afterward? If I understand correctly the actual transfer eventually took them a couple of days, but it had a few false starts and issues. I’ve been talking with the project manager of the LLVM project and a few other people that performed similar migrations in the past, so that we could learn from their mistakes and avoid them. I can ask him about the impact of the migration, even though their goals and priorities were somewhat different from ours. > [@eric.snow](#): > > 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. The [migration plan](https://github.com/psf/gh-migration/issues/13) describes this in more details, but basically we are doing what you described: 1. make bpo read-only and export all issues 2. import all issues in an empty repo 3. transfer the issues from the empty repo to `python/cpython` The first step takes about half an hour, the second step about a day, and the rest is taken by the third step. The third step is already handled by GitHub from their backend and we don’t have control or opportunities to optimize it unless we decide to import a smaller subset first (e.g. only the open/active issues) and open up the issues to everyone while the older issues are still being transferred (this is possible, but will mess up the ID order). There is some room for optimization during the second step, but we have to see if it’s worth the extra time/complexity/risk. > [@eric.snow](#): > > 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. Exporting old issues and marking them as read-only as they are exported is technically doable, but will require some work. The main issue with this is that if we can’t keep the “issues tab” disabled on GitHub during the transfer, people will see some old issues appearing on `python/cpython` and might start interacting with them and creating new ones before the migration is completed. We are currently looking into possible solutions to fix this, so stay tuned 🙂 --- _[View the full topic](https://discuss.python.org/t/github-issues-migration-is-coming-soon/13791)._