Related work items in Commit link to work item ID from old system

[jmillerpolezero]

I have successfully migrated many repos and work items from TFS 2017 to DevOps Server 2022 (on-premise). One problem I am seeing is that when a Commit was made from a Pull Request, the Commit is migrated, but there is an issue with the "Related work items" links. The URL is correct except for the Work Item ID - it is trying to use the old TFS work item ID instead of the new DevOps Work Item ID, so the links are broken. Interestingly, at the bottom of the Commit screen, there is a "Work items" section where the correct DevOps Work Items are attached, and those links do work. It is just the "Related work item" links in the Description section which are incorrect. Is this normal? Is there any way to get have the migration update these URLs to point to the new migrated Work Items?

[sbaeurle]

Hi @jmillerpolezero,

did you find a solution to this problem?
I'm currently thinking of writing a small script to rewrite the repo history with new commit ids.

[jmillerpolezero]

@sbaeurle No, I have not found a solution yet.

[MrHinsh]

No edit is made to either the Git commit message or to the description fields.

Why?

• Git Commit Messages - We just don't exit git at all, so the tagged workiem ID's will be the old ID and only the work item links will be updated.
• Description fields - This is the bigger problem and has been raised a few times. To resolve this it would require a post-migration update (once all of the source work items exist in the target) to go update all of the links. At the time of saving the "description" for Work Item A that has a link in the description to Work Item B we may not have yet created Work Item B.

[sbaeurle]

Thanks for the clarification @MrHinsh. That was my observation so far! I'm currently working on an extension for devops that may enable the automatic usage of a separate reference field which would stay the same during migration.

If this is indeed the way we will go, I will update this discussion accordingly and publish the extension

[blamb21]

@sbaeurle did you have any luck with external script and/or extension to help re-write those commit descriptions? Running into the same thing, and our devs are complaining (even though the work items at the bottom are correct).

[MrHinsh]

We now have a "StringManipulator" that can be used to strip out the links in descriptions... or to reformat them into a new format. Like "~OLDPR|345|~~" so folks know the ID but that its from the old system...

[sbaeurle]

@blamb21 what i did. was to introduce a separate reference field to our PBIs, which is autogenerated from the migration configuration, as well as from when creating new work items.

This is used by a custom devops extension that searches for these fields and displays the correct work item there.
Sadly there are still a few open points there:

1. you can't extend the commit message generation so for new commits you need to manually add the references which is a pain
2. you need to open a separate modal to list your linked work items

I haven't found a solution for both problems yet