How do I move Work Items from one organization to another

Question

We have a number of Work Items in a project. Now, there is another organization in our devops and we wish to move all our existing Work Items from the old organization (project) to the new one. How can this be done?

I've seen people discussing this before, and some comments saying "we use excel". But no information about how to actually do this.

Avisavitaminosis

Answer 1

There is no built-in solution for this. For Excel there is a trick that does a best-effort migration, you do loose some things.

• Create a Tree based query in Azure DevOps that has all the work items you want to migrate
• Open Excel
• Use the Team tab to pull in the work items you want to migrate
• Click New List and connect to the source organization
• Select the Work Item Query you created in the first step
• Click Choose Columns and add all columns

You now have the data you want to import in one excel file. Create a new excel file to push the data to the other account:

• Open Excel
• Use the Team tab to pull the work items
• Click New List and connect to the target organisation
• Select the Input List so you're not bound to a query
• Click Choose Columns and select all the same columns in the same order
• Click Add tree level and convert to parent child
• Repeat Add tree level to match the depth of the source excel
• Copy all the fields from source to target excel file
• CLEAR THE ID COLUMN ON THE TARGET EXCEL FILE
• Fix issues that appear (usernames, area paths, project name etc)
• Hit Publish to create the work items in the target organisation.

What gets lost

You will loose the following:

• HTML formatting
• Attachments
• Links other than Parent-Child
• Some dates will reset (Created, ...)
• Some process workflows may prevent creating work items in the correct state
• Custom board columns
• Revisions of the work item

Alternative

There are tools like Martin Hinshelwoods Migration Tools that can replay work item history from one account to another. It takes a bit of effort to update all the configurations, but it will do a much better job at copying your work items over.

See:

• https://marketplace.visualstudio.com/items?itemName=nkdagility.vsts-sync-migration
• https://dev.azure.com/nkdagility/migration-tools/_wiki/wikis/docs?wikiVersion=GBmaster&pagePath=%2Fgetting%20started&pageId=5

Maida

"Use the Team tab to pull in the work items you want to migrate". What Team tab? – Avisavitaminosis

learn.microsoft.com/en-us/azure/devops/boards/backlogs/office/… – Maida

Thanks. But when I select the Work Item Query that I created before, I get a popup with an error: "TF80076: The data in the work item is not valid or you do not have permissions to modify the data. Correct the problem and retry." – Avisavitaminosis

Tried the same with another query, then it worked. Following the rest of the steps now – Avisavitaminosis

"Repeat Add tree level to match the depth of the source excel". I press the "Add Tree Level" button but it doesn't seem to do anything. What's supoosed to happen at this step? – Avisavitaminosis

I skipped that step, and publish fails with an error saying that 10 items did not publish. I get a "Validation Error", some of the work items contain "unsupported field values". Any tips on how to fix this? – Avisavitaminosis

You probably need to fix the users, iterations, areas, etc manually. Some fields may have rules and you either need to turn off the rules or flow the items through it in multiple saves. – Maida

Can you please elaborate what you mean with "Repeat Add tree level to match the depth of the source excel"? Every time I click it there is another column added: Title(n). So how do I determine the appropriate number of these? – Avisavitaminosis

It depends on the depth of your source. If your source has up to 8 levels of parent childs, your target needs to match that before you copy paste de data. – Maida

How do I determine how many level of parent childs my source has? (What even is a parent child?) – Avisavitaminosis

Work items can be linked from epic->feature->pbi/user story->task forming a tree. for a task (child) the user story/pbi is the parent. By querying the source work items, levels will automatically be generated matching the source data. – Maida

I gave up. Cannot really say if this method works or not, if someone else confirms that it works I'll mark as solution. – Avisavitaminosis

is there any solution that can keep custom columns? – Sialagogue

Answer 2

I did this recently and it involved some more steps than @jessehouwing mentioned in his answer. Below are the steps I took.:

1. Check the DevOps Project Process
2. Change the Project Process
3. Create Query to Get the Work Items
4. Install the Azure DevOps Office Integration Tool
5. Get Data From Azure DevOps in Excel
6. Publish Work Items to Destination DevOps

If you would like to know how you can do each of these steps, please read this article, where I explained everything in detail.

Yesman

With your trick, do you lose anything with the migration or are the work items, linking, history, details, etc. are exactly the same in new org than that in previous org? I read your article but there isn't a mention of this. – Ellerey

@Ellerey Yes, it moves everything, including the linking, history, etc. – Yesman

I am running into an error - since during an import, the work items are getting created as "New" it is not exporting work items in their accurate state. e.g., error I am getting is State "Resolved" doesn't exist -- even though i made sure all the process templates and fields are exactly the same in both orgs.. – Ellerey

When I removed the state field, and person-related fields like created by, assigned to, etc. I got the work items imported by there are no attached files plus all the history is lost in the imported items. It shows "created new" with no history or comments. – Ellerey

@Ellerey Are you sure that the Process of both projects is the same? Please check the article again to verify that. – Yesman

is there any solution that can keep custom columns? – Sialagogue

Answer 3

The original answer by jessehouwing worked great for me but it did take me awhile to figure it all out. Here are a few things that might make it go more smoothly for you.

1. Make sure your query in ADO is a parent-child query and not a dependency query. I suppose you could do it either way but the power of this method for me was in the ability to keep the parent-child relationship. Also, you don't need the parent column in the data. The hierarchy is maintained by the tree levels as stated (this made perfect sense once I figured out my original query was a dependency tree so it may not need to be said but just in case).
2. New items in ADO Agile require the state to be "New". To get around this limitation I just published without the state column first. Then I added the state column, copied the data into, and published a second time.
3. Iteration paths can be copied but the new work space needs to have the name of the iterations matching the names in the old work space. I was only pulling over 4 iterations worth of data so I just added all four iterations to the new work space and everything matched up nicely.

Thanks for the assist. Hope this helps the next person.

Selah