A Step-by-Step Guide to Migrate Tfs to Azure Devops

Migrating from TFS to Azure DevOps can be a daunting task, but with a clear plan, it's achievable. First, assess your current TFS environment to understand the scope of the migration.

To start, you'll need to plan your migration, including identifying the sources and targets, and determining the best approach for your organization. This involves evaluating the size and complexity of your data, as well as the number of users and projects involved.

Next, you'll need to prepare your Azure DevOps environment by creating a new project collection, and configuring it to match your TFS environment. This includes setting up the same work item types, process templates, and security settings.

Before you begin the actual migration, make sure you have a backup of your TFS data, and that you've tested the Azure DevOps environment to ensure it's working as expected.

Recommended read: Migrate Data to Azure

Before you start migrating your TFS to Azure DevOps, there are a few things you need to take care of.

You should complete the Prepare test run phase before beginning a test run migration. This is a crucial step to ensure a smooth transition.

Make sure you're running the supported versions of Azure DevOps Server. As of now, the two latest releases are supported, which are Azure DevOps Server 2022.0.1 and Azure DevOps Server 2022. If you're running Azure DevOps Server 2020.1.2, that's also supported.

If you're running the validation from a server other than the Application server, don't forget to include the Connection Strings Parameter.

Here are the supported versions of Azure DevOps Server:

Preparation is key before migrating your TFS collection to Azure DevOps. It's essential to take your collection offline and detach it to prepare for migration.

To do this, you'll need to complete five steps: take the collection offline and detach it, generate a DACPAC file, upload the DACPAC file and migration files to an Azure storage account, generate an SAS token to access the storage account, and complete the migration specification.

You should also create a SQL sign-in for the database and assign it the 'TFSEXECROLE'. This will ensure a smooth migration process.

Here are the steps to prepare your collection for migration:

Remember to create a SQL sign-in for the database and assign it the 'TFSEXECROLE' before proceeding with the migration.

Before you start migrating your data, you need to prepare your collection for the process. This involves detaching the collection from Azure DevOps Server to transfer user identity information that is stored outside of the collection database.

To detach your collection, you can do it from the Azure DevOps Server Administration Console on your Azure DevOps Server instance. This will make the identity portion of the migration executable.

You should keep the collection detached until the migration completes, as there isn't a way to migrate the changes that occurred during the migration. Reattach your collection after you back it up for migration.

To prepare for migration, you'll need to complete five steps: take the collection offline and detach it, generate a DACPAC file from the collection, upload the DACPAC file and migration files to an Azure storage account, generate an SAS token to access the storage account, and complete the migration specification.

Here are the five steps in more detail:

It's also a good idea to create a SQL sign-in for the database and assign it the 'TFSEXECROLE' to ensure smooth migration.

By following these steps, you'll be well-prepared for the migration process and can ensure a successful transfer of your data.

Setting up a staging server is a crucial step in the migration process. You'll need to install the latest version of Windows Server on your new virtual machine (VM). Ensure you have plenty of hard drive space available.

Installing the SQL Server is the next step. Make sure it's the same version as your live TFS server, as this will help prevent any compatibility issues. This will also allow you to replicate the same environment as your live server.

Installing IIS from Windows features is also necessary. This will provide the necessary infrastructure for your Azure DevOps Server. Finally, install the Azure DevOps Server, ensuring it's the same version as your TFS server.

Explore further: Azure Tfs

To determine the type of migration you need, you'll want to consider your goals. Do you want to test the migration process or use it for production purposes?

A test run is a great way to go first, as it allows you to see how the migration will work without affecting your live data. This type of migration is deleted after 45 days, so it's perfect for testing.

You can choose to queue the import as either a test run or a production run. The ImportType parameter determines the migration type, which is either TestRun or ProductionRun.

Here's a breakdown of the two options:

We always recommend starting with a test run migration to ensure everything goes smoothly.

Validation is a crucial step in the migration process. You need to validate each collection you want to migrate to Azure DevOps Services.

The validation step examines various aspects of your collection, including size, collation, identity, and processes. Run the validation by using the Data Migration Tool. If the Data Migration Tool flags any errors, correct them before proceeding.

Check the logs after validation is completed and fix any errors that arise. Most common errors occur when there are custom process templates with custom fields or states. If the collection is huge, with the largest table size over 33GBs, consider using the SQL Azure VM Method for import.

You might enjoy: Manual Validation Azure Devops

Migration is a great way to get automatic updates from Microsoft, which is a huge benefit. This means you'll always have the latest security patches and features without having to lift a finger.

Optimizing financial costs and reducing operational time are also major advantages of migration. By streamlining your operations, you can save money and be more efficient.

Complying to certifications is another important reason to migrate. This includes certifications like ISO 27001, SOC 1, SOC 2, and HIPAA BAA, which are essential for many businesses.

You'll also be able to access the platform from anywhere and on any device after migration. This is especially useful for remote teams or those who need to work on the go.

A 99.9% uptime guarantee is another perk of migration. This means you can trust that your system will be up and running most of the time.

Lastly, migration provides access to support, which is crucial for resolving any issues that may arise.

Curious to learn more? Check out: Azure Devops Basic vs Stakeholder

Validation is a crucial step in the migration process. You'll need to run the validation using the Data Migration Tool to examine various aspects of your collection, including size, collation, identity, and processes.

Each collection must pass the validation step before you can proceed with the migration. If the Data Migration Tool flags any errors, you'll need to correct them before moving forward.

Custom process templates with custom fields or states can cause errors during validation. Fixing these errors is essential to ensure a smooth migration process.

Large collections with the largest table size exceeding 33GBs require a different approach. You may need to use a SQL Azure VM method for import.

After validation is completed, check the logs for any errors. Fixing these errors is crucial to ensure the migration process runs smoothly.

You might like: Azure Data Migration Assistant

The main log file is named DataMigrationTool.log, and it contains details about everything that was run.

You might notice several logging files in the log directory, making it easier to focus on specific areas.

The ProjectProcessMap.log file is worth reviewing if TfsMigrator reports an error in the "Validating Project Processes" step.

For large collections with a largest table size over 33GBs, a SQL Azure VM Method is required, and you should check the logs after validation is completed.

The TryMatchOobProcesses.log file is only relevant if you're trying to migrate your project processes to use the inherited model.

The identity map log is of equal importance to the actual data that you migrate to Azure DevOps Services, and it's essential to understand how identity migration operates.

Active identities can sign in to Azure DevOps Services, but historical identities can't.

Discover more: Azure Devops Managed Identity

The identity map log is a crucial file in the migration process. It outlines the identity map between Active Directory and Microsoft Entra ID.

This log file is of equal importance to the actual data being migrated to Azure DevOps Services. You should review it carefully to understand how identity migration operates.

Active identities can sign in to Azure DevOps Services, but historical identities cannot. This is a key distinction to keep in mind as you review the identity map log.

The identity map log file is similar to the example shown, with the Expected Import Status column indicating whether an identity is active or historical.

Here's a breakdown of the Expected Import Status column:

Understanding the identity map log is essential for a successful migration. It will help you identify any issues or discrepancies in the migration process.

It's essential to have a rollback plan in place before doing a final production run. A test run is highly recommended to ensure you can test the migration settings provided to the Data Migration Tool for Azure DevOps.

Detaching the team project collection from Azure DevOps Server makes it unavailable to your team members, which is crucial for a successful rollback. This allows you to roll back the production run and bring the on-premises server back online if needed.

If this caught your attention, see: Azure Devops Server

If you're unable to determine the cause of the failure, you can contact Azure DevOps Services customer support for help. Customer support tickets can be opened from the page https://aka.ms/AzureDevOpsImportSupport.

Rolling back the production run is a relatively simple process, but it's still essential to have a plan in place. This includes detaching the team project collection, rolling back the migration, and bringing the on-premises server back online.

Recommended read: Azure Devops Support

The migration process is straightforward with OM4ADO, allowing you to migrate from Azure DevOps Server (TFS) to Azure DevOps (VSTS) with ease.

You can choose to migrate multiple projects or single projects as per your requirement, and select the data you wish to migrate from various options such as work items, TFVC with labels, area and iteration, query, dashboard and widgets.

To start the migration process, click on New Migration and enter the Azure DevOps server parameter as the source endpoint while Azure DevOps service parameter as the target endpoint. The tool will validate and configure the systems, allowing you to migrate successfully.

Here are the key steps to keep in mind:

To run a migration, start with a successful test run migration before attempting a production-run migration. This allows you to see how the migration will look, identify potential issues, and gain experience before proceeding.

It's essential to verify that the Microsoft Entra tenant policy isn't set or that there's an exception for the user performing the migration. If the policy is turned on, your migration will fail to finish.

Azure administrators can prevent users from creating new Azure DevOps organizations, which may cause migration issues. If you're experiencing problems, check that the policy isn't set or that there's an exception for the user.

Azure DevOps Services doesn't support per-pipeline retention policies, so they won't be carried over to the hosted version.

If you need to repeat a completed production-run migration for a collection, contact Azure DevOps Services Customer Support before queuing another migration.

Expand your knowledge: Azure Devops User Story

Here are some key things to keep in mind when running a migration:

Migrating from an on-premises environment to the cloud can be a daunting task, but with the right tools and knowledge, it can be a seamless process.

You can migrate from Azure DevOps Server to Azure DevOps Server/Service or any combination of the two instances without needing to upgrade your existing Azure DevOps Server. This means you can directly migrate from existing versions whether it's 2010, 2012, 2013, 2015, 2017, 2018, 2019, and 2020 to Azure DevOps Services.

To start the migration process, you'll need to create projects manually in the target system with the exact name as in the source system, including space, numerical, and special characters. This is a crucial step to ensure a smooth migration process.

Here are the versions of Azure DevOps Server that you can migrate from:

Make sure the endpoint user has the correct access level, specifically Basic level access, when migrating a project with changeset. This will prevent any errors from occurring during the migration process.