When it comes time to transfer data between Azure DevOps instances, it is important to understand the benefits and limitations of each type of transfer. Data can be moved on an instance level and a project level within Azure DevOps. It can also be moved from Azure DevOps Server on-premises to Azure DevOps Services in the cloud. In this post, we will discuss each type of transfer, as well as scenarios in which each may be appropriate.

Instance Level Transfer Within Azure DevOps Services

In this type of transfer, ownership of data is moved between organizations from one Azure DevOps cloud instance to another. We might also see this during a subscription ownership transfer, or when moving Azure DevOps users from one Active Directory domain to another. This type of transfer is quite simple and doesn’t require major changes. The move can be completed in less than an hour and will require a minimum of two days of planning and preparation.

 

Lift-and-shift On-Premise Collection to Azure DevOps Services

This is a slightly more complicated data transfer. Here, data is moved from an on-premises collection to a cloud instance. It is a lift-and-shift operation, but there are some limitations. For example, rarely-used work item template elements like state transition rules may not be migrated. Furthermore, you may decide to make minor changes before the lift, such as refactoring your application in order to make it work more effectively in the cloud. This type of move is executed over a weekend to minimize downtime and will need between one and three weeks for planning, preparation, and dry run. The time required depends on the size of the collection, the level of customization, and the current on-prem version.

 

Migrate Project Data Between Azure DevOps Instances

This is the most effort-intensive data transfer. This might be used during a company split, reorganization, or acquisition in which Azure DevOps instances need to be divided or consolidated. Lift-and-shift is not a viable option here, as we cannot simply move a copy of the data as it is. Work item IDs will change during the migration. In addition, pull requests and history of Pipelines and Releases cannot be transferred. Similarly, TFVC Source Control history can only be migrated to a Git repository. This type of move is executed over a weekend to minimize downtime and it will need between two and six weeks for planning, preparation, and dry run. The time required depends on the amount of data to be transferred and the level of customization of the Azure DevOps Instance.

Need some help with your transfer? Not sure where to start? Contact our team of experts today.