solidify / jira-azuredevops-migrator

Tool to migrate work items from Atlassian Jira to Microsoft Azure DevOps/VSTS/TFS.
MIT License
262 stars 223 forks source link

Missing Links in ADO Migration (could be due to JIRA project key change? ) #1059

Open Geethika-Krishnan opened 1 month ago

Geethika-Krishnan commented 1 month ago

Describe the problem

I am experiencing an issue with migrating project links from JIRA to ADO following a project name and key change. Originally, the project key was OTE. After working on this project for some time, the key was changed to RTE. The problem arises with the links between items in the project. While these links appear correctly in the individual item JSON exports from JIRA (showing the old project key OTE), they are not established when the data is imported into ADO. During the migration process, these links fail to map correctly in ADO, resulting in missing links.

To Reproduce

Steps to reproduce the behavior:

Tool version v3.0.328

Attachments

Screenshots

Item RTE-1596 in JIRA with 2 linked items, RTE-1474 and RTE-1388

image

In the exported json file of RTE-1596, links are shown as, image image After import, this is the ADO work item's link section (RTE-1596) image

At the same time, if I were to go into the individual item json and manually change the link from OTE to RTE, it gets established in ADO.

image (manually changed 'OTE-1474' to 'RTE-1474' in RTE-1596's json.

This is how ADO shows links when exported after the manual change. image

Alexander-Hjelm commented 1 month ago

Marking as a bug, but we will not commence work at the moment. I am so far unsure of whether or not there is anything we can do in the tool to counteract faulty/missing data from the Jira Rest API.

The first possible solution that comes to mind would be to do a search replace on a regex pattern, for example the following:

"TargetOriginId": "(OTE)-\d+",

Here, capture group 1 would be replaced with RTE, where OTE is the original project key and RTE is the new project key. This would effectively preserve the issue number but modify the project key.

Such a solution would need to be toggleable from the config.json file.

One workaround would be to perform the above search-replace operation manually across all .json-files in the migration workspace (top level files only), for example using visual studio code or a scripted solution. Have you tried that? The search-replace operation must be performed prior to the ADO import.