The list above is just a first attempt to sort the tasks involved in the strict migration. Leaving the rest to @Aklapper and @chasemp.

I was thinking about creating a task "Start the Bugzilla migration" that would have all the real blockers that would impede the start of that point of no return. Then here we document what comes right after "Start the Bugzilla migration" until the launch. What do you think?

why not limit the bugzilla-migration tag to only these tasks and then the list isn't a manual thing? That was my intention at least. Anything with the bugzilla-migration task is part of the migration only, same with rt-migration.

The intention of the manual list is to document the sequence of steps from the moment we start switching off services and during the 1-3 days that the migration might last. At that point everything needs to work like a clock and everybody needs to know what to do. I fear the workboard alone will not be enough...

Bugzilla-Migration contains more tasks that must be completed before, or that are not in the critical path of the strict migration. Still, I think it is useful to have them assigned to this project. Otherwise it might be easier to overlook some detail, or let something fall between the cracks.

You are the one that will give the marching orders during those 1-3 days, and I'm happy to follow the method that you think it's best.

... or I can just maintain this sequence of steps directly in https://www.mediawiki.org/wiki/Phabricator#Migration_timeline

This is what I will do, unless someone has better ideas here.

What I would like to do is stick w/ a non-manual list. Use the bugzilla-migration tag as authoritiative, and say only things that are critical for migration are high priority. I don't see a real linear sequence there, step 6 and step 7 can happen in either order, etc. It seems like the best chance of accuracy is to keep the grouping with as close a relationship as possible to the actual task sorting. We should use the tag for grouping, priority for sorting what is and is not at the top of the list, and a workboard for ordering if you we need to do it somewhere.

I really don't mind if you guys want to keep a manual list somewhere, I just don't think it will keep up and I don't understand the full point of why.

Why, because of all the Bugzilla users out there that will welcome a list of steps to be completed during the migration, before it happens and while it happens.

A factor that influences this task is T473. Will this production instance be accessible during the migration or will it be down during the 1-3 days it lasts? If this instance is available at all times, then yes, marking all the essential tasks as High here is enough. If this instance will be down, then we need this list in https://www.mediawiki.org/wiki/Phabricator#Migration_timeline , being updated as we go. Otherwise everybody will be a lot more stressed than needed.

sure, but would it make more sense to grab a static list for the wiki to satisfy right before migration rather than making it here now and constantly have it be a step behind?

Moving this question here:

In T473#21273, @Qgil wrote:

@chasemp, must Phabricator be down at 00:30 UTC when we start the migration, or is it possible to keep it alive while all the data is exported from Bugzilla?

I mean, does the process start with a full extraction of Bugzilla data (without touching Phabricator), then manipulation of data locally, and then import of the data to Phabricator? I'm asking because it is mainly at the beginning when we need more coordination by more people, and having Phabricator available would be nice-to-have. Otherwise no problem.

In T535#21424, @Qgil wrote:

Moving this question here:

In T473#21273, @Qgil wrote:

@chasemp, must Phabricator be down at 00:30 UTC when we start the migration, or is it possible to keep it alive while all the data is exported from Bugzilla?

I mean, does the process start with a full extraction of Bugzilla data (without touching Phabricator), then manipulation of data locally, and then import of the data to Phabricator? I'm asking because it is mainly at the beginning when we need more coordination by more people, and having Phabricator available would be nice-to-have. Otherwise no problem.

In theory -- yes, Phabricator could still be up while dumping from bugzilla. In practice, the resources being used for extracting content from bugzilla and the resources being used to serve Phabricator are one and the same so it's not ideal without a good reason. I'm also against tiered outage notification, I think once we reach the maintenance window no one should expect anything to be up and all coordination shouldbe done out of band of Phab.

That being said, the migration team itself I had planned on being able to track progress, but intending to use Phab as a point of status coordination during this window isn't a good idea.

Makes total sense, thank you.

@chasemp, a question of detail: at some point we need to kick bzimport. Should this be added to the timeline? Also, will we wait until bzimport is done, or (if we have finished all the rest) wiill we open while bzimport is doing its job?

In T535#22267, @Qgil wrote:

@chasemp, a question of detail: at some point we need to kick bzimport.

what does this mean?

In T535#22286, @chasemp wrote:

what does this mean?

I guess at some point after all data has been migrated, you create bzimport and let it start assigning activity to existing Phabricator users.

I'm asking whether this step should be noted in the timeline as well. I'm also asking whether we need to wait bzimport to finish the work with all the existing users before opening shop or once bzimport is running we can forget about it.

ah ok -- so the bzimport user will exist from teh beginning since it is used for all actions. The metadata update is done by two cron jobs which I plan to configure before the end of the window. The crons are throttled to prevent thrashing phab overall and they will run until they catch up to the existing users and run periodically for new users. So every one is treated the same, and the job itself handles it from there.