how to migrate issues to a new custom workflow

[Mike Chiaramonte]

Our project would like to move to a custom issue type and workflow (with different status fields, post prod validators and functions etc.) rather than continue using an issue type that is shared across multiple projects. Currently around 800 issues exist for this project/issue type. Upon moving to the custom workflow we need to maintain the data that exists. Consequently, we have a few questions we need answers on to ensure this occurs successfully:

-How should we migrate the issues to the new custom workflow? We can't edit the existing workflow since it's shared across multiple projects. Can we export the issues from the current issue type into the new issue type?

-When we migrate to a new issue type with new statuses, how can we maintain all of the JIRA history? E.g. time spent in each workflow step.

-How can we handle an enhancement in status such as In Testing (we are splitting it into “In QA” and “In UAT Testing” in the new workflow). Can we do a mapping of statuses?

-Is there a particular order that disabling of existing workflow from the project and creation of the new workflow should be carried out in? If so what is it?

-Any other recommendations to carry out this change in JIRA in particular around ensuring existing data history is kept?

-On another topic - is there a way to require the user to update a free-text field when the user updates the fix version of an issue?

[Nic Brough -Adaptavist- · Accepted solution]

1. You'll need to create a new workflow scheme, one that associates the new workflow with the new issue type. I'd copy the existing scheme and add to it.

2. The history of the issues will be untouched, except for new lines saying "workflow was changed", and, possibly "status" as well

3. Yes and no. Jira will ONLY ask you about issues where you are REMOVING an existing status from a workflow. If you do that, it needs to know what status in the new workflow to flip the issues over to, but it won't ask you about anything else. In your example, you'll be asked to change "in testing" (it sounds like you are removing that) to something, but it'll either be In QA OR In UAT Testing. It has no way of knowing which is which.

4. Create the new workflow. Create the new scheme. Associate the new scheme with the project. If the old workflow is now completely unused, you can delete it.

5. Actually, not really. Changing workflows won't lose you any data.

6. Make the "edit fix version" option into a workflow thing and stick a validator on the transition...

[Mike Chiaramonte]

Thank you. Per your advice, to create the new custom issue type we plan to clone the workflow/schema associated with the existing issue type that is shared across projects and then modify its workflow and schema as needed. How do we port or migrate the existing issues associated with the existing issue type? Do we copy all of the issues when we clone and modify the issue type? Or do we port the issues over to the new issue type once it’s already created? What is the best way to do it? It is very important that we transfer the history of the existing issues so we can continue to analyze data such as time spent in workflow statuses in reports such as the Control Chart. If it's possible to copy the issues and then archive the existing issues in the old issue type, that would probably be preferable.

[Nic Brough -Adaptavist-]

The easiest route is to create the new workflow and schemes, then use bulk-edit to change the issue type on the issues you want to change.

However, one thing jumps out at me - this is one project that wants to change its workflow. There's actually no need to change the issue type at all. You could just create the new workflow, and then create a new workflow scheme that say "for issue type X, use new workflow" (the existing scheme will say "for issue type X, use old workflow), and apply that to the project.

When you do the migration, the only data change will be the one in point 3 in my answer. Nothing else will change at all.