Huge migration from Fogbugz - WF approach

[Per-Åge Themte]

Hi,

We're migrating from Fogbugz to Jira some time this fall. Our FB instance consists of 600 users, 85k cases devided by around 100 projects. Out of the 600 users, 450 of them are customers and the rest are in-house consultants.

I've now prepared pretty complex workflows in Jira (as our organisation is complex) and have one per the four issue types we're going to use. In all WF's, the status both describes where the issues at in the process as well as between customer and consultant (e.g in development = consultant vs. in QA = customer)

Since Fogbugz doesn't have the same complexity, we haven't used statuses there - only active and resolved. Hence, there's an issue with mapping.

My suggestion:

• Have all account managers go through open cases in Fogbugz and make sure they have the right issue type prior to migration
• Copy the new workflows and remove all transitions, making all statuses available
• Import all cases into temp workflow - all cases will then have the same status (open/closed)
• Bulk edit all cases changing statuses based on assignee - split between the best option of status for assignee; customer vs consultant (i.e if assignee = consultant then status = in development. If assignee = customer then status = More information needed)
• Have account managers again go through open cases and set correct status
• Once that is done, during the migration weekend or maybe after a few weeks, change the WF scheme to the first one with more rigid transitions. I assume that will work perfectly as I can change status 1:1 (They're all the same)

Is this a valid and good approach?

Thanks in advance!

[Earl McCutcheon · Accepted solution]

Hello Per-Åge,

This looks like a good plan except where you noted using the Assignee as your unique identifier to split the issues up during the Bulk edits as this will introduce a bit of overhead as you noted having approximately 600 users and each user in an assignee field is going to require its own bulk edit action as you would not have an option to group various assignees easily, so you may theoretically need to run 600 different bulk updates depending on the assignee count of open issues.

Alternatively I would recommend having your account managers, during the initial run through the cases, flag them with a custom field with either Customer or Consultant that can be mapped to a Jira custom field during the migration and used as the unique identifier in the bulk edit therefore limiting the bulk operation to two in the post migration data clean up rather than once per user.

Other than that I would also recommend setting up a Staging Server to do a dry run on the migration and data manipulation to make sure everything turns out as planed.

Regards,
Earl

[Per-Åge Themte]

Hi @Earl McCutcheon! Thanks for weighing in :)

I totally agree, and while I wrote assignee, I actually ment groups. We're going to have all users in either [our company] or [external-customer company]. With that it should be easy to use the "members of" JQL to create necessary filters. Either way - bulk edits on cloud is limited to 1000 cases at a time, so we still have to run this several times. Do you see any issues with parallell processing with multiple browser sessions or users sessions (utilizing account mgrs to do the same..)?

Also - we have dry-runned this one time into a separate cloud staging instance (normal cloud instance, but with < 10 users) , and will perform one more UAT before migration weekend. 

[Earl McCutcheon]

Hey @Per-Åge Themte,

Thanks for the clarification and with only two groups that really narrows it down and using something like "assignee in membersOf()"  totally does the trick.

If you are having multiple users running individual issue updates in tandem for the verification steps I see no problem as each workflow action is going to launch an index event at the time that action occurs, and if there is a data consistency conflict by a secondary user trying to trigger a conflicting update you get a warning popup that the action cannot be completed, and to refresh and try again.

BUT if your using bulk operations for the follow up corrections, these are quite resource intensive by themselves which is why the limit is set to 1000 to prevent overloading the system so a performance factor comes into play.

Then, if your planning on running the Bulk Updates in parallel by different users, I would recommend against this first for the performance issues that can arise mentioned above and also to verify there is no overlapping conflicts in the data that is being updated. The issues in a Bulk operation are all loaded into memory up front and bypass the index check at time of update to verify the data is in the same state it was when you started to load it all into mem at the start of the update and then completes the index across all the issues in one go after the change is applied, and you run the risk of either overwriting another users changes or applying both changes with a conflict. 

It basically comes down to which ever change was last applied takes precedence.  i.e Two users A and B trigger a bulk operation at the same time using a query that overlap issues, User A does a bulk change to set the status to "ABC" and User B sets the status to "XYZ" at the same time,  as the bulk operation is processing each update is going to be applied against the issues in the set and whatever the last run update event was in the sequential actions db side will be the one that sticks, so you could wind up with a mix and mash on the results or even a situation where an issue is in an invalid status.  And in this particular scenario you could hit the error described here "Workflow Invalid Status" if you get split into the wrong status per the intended workflow.

So to summarize Individual updates go for it all day and you wont run into issues, but bulk updates should have a clear ownership of the task to avoide overlapping the updates, and hindering performance.

Regards,
Earl