1

I'm looking to migrate a project from one org to another in Azure DevOps. We've ended up with two or three orgs, and this project that I'm looking to move has all sorts of weird and wonderful work items created and custom fields added. What I'm looking to do is move the project and then see if I can persuade the powers that be that certain things can be dropped but I have an immediate need to move as-is so that reporting and other work isn't impacted.

I have tried to get this to work with the migration tools (and tried to follow the videos) but have hit a dead-end. I think there are two issues potentially. One being the ReflectedWorkItemId. It says that it's not found in User Stories but I'm not sure how to resolve this? Do I go into user stories and add a field called 'ReflectedWorkItemId' and populate it with the work item number and/or add the same field in the destination org process?

It also mentions in the info that it can't find one of the Work Item Types - Processes. There are a few other custom work item types that have been created too but I assume it's given up on the first one. Do I have to create all of the work item types and the custom fields for each work item type in the destination org? Or am I getting the wrong end of the stick with this?

enter image description here

enter image description here

Hi guy
  • 35
  • 1
James
  • 163
  • 1
  • 2
  • 12
  • This repo may have some useful info. Search code and issues for 'ReflectedWorkItemId': https://github.com/nkdAgility/azure-devops-migration-tools – GaTechThomas Aug 13 '21 at 14:39

1 Answers1

2

To provide sync as well as migration it is important that the tools knows which items have already been migrated. This is the purpose of the ReflectedWorkItemId field.

The field is not required in either case, however... if you don't have the field then the system cant be re-run as it will re-copy all completed work items. If you add the field to the target then it will only copy those items it cant find. If you add the field to the source (yes it needs to be the same refname), and set UpdateSoureReflectedId to true then you can also filter the source, using a query and limit what you load.

The former prevents duplicates, and the latter allows you to filter the data load...

This is mentioned in this document. Here is a similar issue you can refer to.

TF201077 that usually happens when the target Project does not have a work item of that name. You can refer to this issue on github for help.

Hugh Lin
  • 17,829
  • 2
  • 21
  • 25