TFS4JIRA Cloud-Native | How to migrate a project with different workflows for each issue type?

Use case:

The user wants to migrate a project characterized by substantial variations in the status and workflows associated with different issue types. In essence, they aim to transition a project where each issue type operates under entirely separate workflow structures, all within the same project.

What happens when trying to configure a profile in TFS4JIRA for such a use case?

Status and statuses mapping allows multiple-to-one or one-to-multiple mapping, but not many-to-many.

In this use case, the user have a Jira project to migrate to an ADO project with the conditions mentioned in the use case above. Note that they want a one-time migration, no live sync is needed.

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, 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 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 by issue type, for example, issueType=Bug, issueType=Epic, etc. 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.

Losing the links between the issues would not be an option for our client. 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.

 Workaround

The third option is using only one profile. That would mean that within the same profile, the links between issues would not be lost. The user would need to respect Hierarchy and migrate the issues in the following order:
1. Epics
2. Bugs, Tasks, Stories, …
3. Subtasks.

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.

Instructions:

1. Create a profile with all the mapping and configurations specific to Epics

2. Apply a filter in Filters, Jira JQL issueType=Epic

Open

3. (OPTIONAL) At this point the profile is ready to perform a migration, so as a backup: Clone the profile to save the configurations, this new cloned profile should NOT be used for migration.

4. Start initial sync that should include ALL epics, be sure to add an old date that doesn’t exclude any older issues. To be sure, go to the Jira project and run the JQL applied in the filter, check the number of issues. They should ALL be migrated at this point.

5. After Epics are all migrated, go edit the same profile and repeat steps 1-5 for a different issue type by using the hierarchy order.

 Related articles