...
The first thing we tried was to map all the different statuses on Jira to one status in ADO. However, we quickly noticed that would not work well for them because, because for example, in issue-type Bugs, one status would mean a different thing than the same status would in the Tasks workflow. A migration with this kind of mapping would cause confusion for confuse the team working on the project, and the status would be meaningless.
The second option would be to create a different profile for each issue type, using a JQL in the Filter filter by issue type, for example, issueType=Bug, issueType=Epic, and so onetc. Doing this and then migrating in order or hierarchy, first Epics, then Bugs, Tasks, Stories, and Subtasks in the end, would solve the status mapping problem. Although, in. In the Cloud-Native version, one problem arises , is the linking between issues is made within the profile, for that reason, issues migrated with the profile filtered for Epics would not be linked to the issues migrated with the profile filter by Bugs, and that would apply to all issue types.
| Note |
|---|
Note that using the Self-Hosted version would not pose this problem, it’s . It is possible to have different profiles and link issues between them. |
Losing the links between the issues would not be an option for our client, especially . Especially when talking about Epics and subtasks, that information is essential for the workflow and hierarchy of the issues. They also didn’t want to use the Self-Hosted version , because it involves installation on a Windows machine.
...
Why would this work? Because it’s a one-time migration, the user doesn’t need live synchronization, so it’s okay if the mapping of already synchronized issues is lost/edited as it will no longer be used.
...
Create a profile with all the mapping and configurations specific for to Epics
Apply a filter in Filters, Jira JQL
issueType=Epic
...