How can i Migrate from Azure DevOps services to Azure DevOps Server

Question

I am having my project collection running in Azure DevOps Online(Services). And I would like to migrate that to Azure DevOps On-Prem Server.

Help me out here with the incompatibility issue i will be facing and how to overcome that.

Options to Migrate from Azure DevOps online(services) to Azure DevOps Server(On-Prem).

Is there any services available in azure to successfully acheive the above migration with out any data loss?

Should I must use third party tool to do the above migration with out any data loss?

Help me out here with the Downtime required for the 100 GB of Project collection with multiple repository.

Project Collection size - 100 GB

Answer 1

You can use the Azure DevOps Migration Tools which is what would be recommended by Microsoft.

There is no way to migrate data full fidelity, and these tools do the best job possible within the bounds of the APIs available. They use the original Object Model API that support TFS 2013+ (and there are some fixes in there to support 2010+).

Things you cant migrate:

• Build runs
• PRs
• Test runs

Answer 2

One of the previous answers (since deleted?) has captured most of the critical points, and that no tool can migrate 100% of data with zero data loss (Actually, 100% migration with no loss is not feasible as inherently some of the automatically generated and configuration values, like work item ids etc., will inherently be different between two instances). Therefore, the only way to get zero data loss migration is to lift and shift the complete project collection image from Azure DevOps Services to Azure DevOps Server, which is not supported by the official Azure DevOps migration tool. Given that, the only way left to migrate data is using Azure DevOps APIs.

So, the best approach is to understand what data cannot be migrated by the migration tools that you are evaluating, and then decide what works best for you. Also, it will not be a black and white selection when it comes to choosing a migration solution. First, you need to define the must-haves you expect from migration and then evaluate the different migrators available in the market. Here are a few common selection criteria:

• Data Loss:

Understand what data can be and cannot be migrated by the migration solution. Ideally, the tool should be able to migrate work items (along with history, attachments, mentions, and inline images) and test management, including Test Results, Source code, Dashboards, Areas and Iterations. For Builds and pipelines, you can use the native Export-Import feature, as they require manual changes to tweak the connection.

• Zero Downtime:

Downtime adds operational costs and impacts development operations as teams cannot use Azure DevOps tools. Understand thoroughly that there is no scenario in which downtime will be required for any type of data.

• Ease of Use:

Some tools are a collection of unsupported scripts (Naked Agility) which require very high degree of sophistication to use. These can be extremely expensive (even though the scripts are open source), error prone and hinder operations.

• Project Consolidation or Customized Templates:

Analyze if you want to consolidate multiple projects into one project while migrating or if the templates need to be customized. If that is the need, evaluate if the migration tool can support such configuration with ease and has a UI to do so. Manually configuring mappings for each project can be tedious and highly error prone.

• Migration Time:

Many migration tools migrate projects one by one, hence consuming a lot of effort and time to migrate the data spread across multiple projects. Understand how many projects can be parallelly migrated to have speedy migration.

• Reverse Synchronization:

Do you want to keep the data in sync between Services and Server for some time post-migration? Will data be integrated bidirectionally or unidirectionally? Answer these questions and then evaluate the migration solution if it will meet the requirements.

• Commercial Support:

Migration can be tricky and time-consuming, as, over time, different teams have created all the odd stuff in there. Better to have a team of experts do the migration for you while you focus on defining requirements and validating the completeness of migration.

Full disclosure: I work for OpsHub.