Migrate or make a copy of existing Azure Devops backlog

Here are the list of tasks we came up with

• Export and import DevOps backlog (including comments, history, attachment, links if possible)
• Export and import DevOps pipeline (including history if possible)
• Export and import DevOps Wiki and Library
• Moving tenancy by switching Active Directory

In this article I will be describing how to export and import Devops backlogs including comments, history, attachment, links, etc.

Pre requisites:

1. Empty Devops Project (Target)
2. Existing Devops Project (Source)
3. Permissions to create, update process Or can be a member of Project Collection Administrators group
4. Azure Dev labs (There are other ways to do it but I felt this one is best, you could run the migration from your machine but it will be slow, its better to host on VM on same region and same subscription where Devops exist

Configuring the Devops project (Target):

1. Disable all notifications:
   All email notifications should be disabled before migration otherwise it will bombard with emails to all users mentioned in the comments, description or any work items.
   The best way to achieve this is disable notification from Organisation as well as Project level
   Organisation: Azure devops > Organisation > Organisation Settings > Global Notifications > Settings > select Do not deliver
   Project: Azure Devops > Organisaiton > select your project > Project settings > notifications > Delivery settings > select Do not deliver and save
2. Above step don’t stop emailing those who are being @mentioned so for that we need to remove all users from the Organisation
   Organisation > Settings > Users > Remove all of them except you, make sure you have atleast 1 admin user.
   When a work item is copied over devops will trigger email to the mentioned emails and fails (after we remove it from users list), so admin user will receive failure email so filter these emails to a folder before migration to avoid email bombarding.
3. Work Item Types:
   Make sure you have all work item types configured on the target project, if it doesn’t our migration will skip those work item types
   To configure work item types we also need to make sure the fields are having same defination name
   Organisation Settings > Process > Select your inherited process >

Work Item Types

Fields in the Work Item Types

3. Server Configuration:

Refer: https://nkdagility.github.io/azure-devops-migration-tools/server-configuration.html

It’s better to create a VM to do this as it will be load heavy operation based on number of items and attachments you have in devops

Create a new Azure Devops lab, Provision a VM, RDC to VM and follow the installation guidelines in next step, make sure you select the same region as the Devops region, follow this link to see how to check your devops region
https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/change-organization-location?view=azure-devops

4. Download and install the migration tool

nkdAgility/azure-devops-migration-tools

Summary:

In order to run the migration you will need to install the tools first.

1. Install Chocolatey from https://chocolatey.org/install
2. Run “choco install vsts-sync-migrator” to install the tools source

The tools are now installed. To run them you will need to switch to c:\tools\MigrationTools\ and run migrate.exe.

Use powershell to run the scripts

5. Configure the tool:

Get a copy of the Configuration File from below link, this file is specific to copying work items only (including attachments, links, etc), we will use it in the tool later.

rohitsies/AzureDevopsMigration

Create temporary folder to store attachments

c:\\temp\\WorkItemAttachmentWorkingFolder\\

Update the Source and Target Azure devops Url in the config file

6. Run the tool

.\migration.exe -c configuration-workitems.json

With config: “FilterWorkItemsThatAlreadyExistInTarget”: true you could run the tool as many times with different configuration

Example:

1. Run the tool just to create work items
   Configuration: Mark most of the stuffs as false, Link Migration, AttachmentMigration, etc
2. then run it again to create attachments
3. then run it again to create links

Or

1. Run the tool only for Work Item Types: Epic
   Configuration:
   “WIQLQueryBit”: “AND [System.WorkItemType] IN (‘Epic’)”,
2. then run it for another work Item Types

ReflectedWorkItemId will have link to the old project work item so it will make sure it doesn’t duplicate things

Known Issues:

1. Htmlattachment embed errors: You may receive error while processing some of the work items, just migrate all items first with “FixHtmlAttachmentLinks”: false and later try again with “FixHtmlAttachmentLinks”: true, atleast the work items will all be copied
2. ReflectedWorkItemId should be available in all work items in source and target, make sure you create it in a separate group say “Migration” or group which is available, I fell into issue where it doesn’t work when I keep this field in group: Process for some reason
3. All work item types should match along with field defination (Display name is different from defination name), if the tool doesn’t find the field it just ignores and doesn’t error so you may loose data in the target devops

Feel free to ask about any questions or issues you have.