The Great Azure DevOps Migration - Part 1: Introduction

This series is going to describe the process I went through to migrate my company's on-premises TFS setup to Azure DevOps in the cloud. The process did turn out to be much more time-consuming than I anticipated, so hopefully this can help future migrators!

This guide will cover the issues I ran into with my setup, you should look at the Microsoft docs for any of your specific issues.

The guide will cover a full dry-run of the migration, and then the final live migration. You must do a dry run first!

On Premises

I'll start by describing my current on-premises setup, and what I expect my final migrated setup to look like.

Version

We transitioned from Visual SourceSafe to TFS 2008 about 10 years ago. Since the initial installation, we have been really good about updating to the latest version of TFS as it was released.

So, our current version of on-premises TFS is running Azure DevOps Server 2019.0.0. TFS was renamed to Azure DevOps Server this year, but it's still just TFS with a fancier name.

If you haven't kept your TFS version up to date, you are going to need to upgrade it to the latest version of on-premises TFS before starting this process.

Collections

We have a single TFS collection named DefaultCollection. When migrating to Azure DevOps, each collection gets migrated as a separate account, so having a single collection is the easiest path forward if you have a small team.

Projects

Inside each Collection, you can have multiple Projects. Each Project can have its own Process template and Project settings. We have about 50 projects, but we actually only use one. When we migrated from SourceSafe to TFS 10 years ago, the migration tool converted each project (per application) into an individual TFS project.

Over time, we consolidated the active projects into a single TFS project. So, only one of the 50 projects is under active development, the rest are legacy apps or abandoned apps that are never modified.

For the move to Azure DevOps, I will be moving only the active TFS Project and leaving the old projects behind. If we need those projects in the future, I will move just their current code base into a new Azure DevOps GIT repository.

GIT vs TFVC

GIT did not exist in TFS when we started using it, so about 4 years ago (?) we migrated all of our active code-bases in the active project to use GIT repos instead of TFVC. We did this inside the current project, so that we could maintain our existing Work Items. That means we currently have a Project containing a TFVC repository and multiple GIT repositories.

For the move to Azure DevOps, I am going to only migrate the GIT repositories, so I will need to remove the TFVC repository before completing the import.

Azure

We already have an account in Azure. We don't host our entire application infrastructure in Azure, but we do host some services there, so we have active subscriptions.

Process

We have made some changes to the TFS Process. Mostly, we've added fields to work items, modified the work item UI, and we've added a few extra work item types.

I believe it will all import smoothly, as we have not made any extreme changes to the Process.

Build Servers

We host two TFS build servers locally. For a few of our applications, we have third-party dependencies that need to be installed on the build server, but the majority of our applications could be built from a non-custom build server.

For now, I plan to use our existing local build servers for all builds, but long-term we should be able to migrate many of our apps to be built in the Azure DevOps service.

What's Next?

In the next post, I will cover setting up the new VM to host the staged TFS installation for migration.

1. Introduction
2. Setup the Staging VM
3. Purge Unnecessary Data
4. Validate the Migration
5. Prepare the Migration
6. Migration Dry Run
7. Live Migration
8. Conclusion