Migrate data from TFS to Azure DevOps Services

TFS Database Import Service

The TFS Database Import Service, also known shorthand as the Import Service, provides a high fidelity way to migrate collection databases from Team Foundation Server (TFS) to Azure DevOps Services. It's recommended that you download the migration guide if you're looking to use this service to import your collection(s). The guide serves as a walk through of the different steps involved in an import. Providing best practices, checklists, and helpful tips to make your import as easy as possible. The guide should be used in conjunction with the more technical documentation referenced below to successfully import to Azure DevOps Services.

Supported TFS Versions for Import


It can take up to 2-3 weeks after a new RTW version of TFS is released for import support to come online for that version. It's important to take this into consideration when choosing to upgrade shortly after a new RTW TFS release.

TfsMigrator for TFS 2018 Update 3 supports TFS 2018 Update 3.1 & Update 3.2 as well. If you run into an issue running TfsMigrator and are on that version, please download the latest TfsMigrator version and try again.

Support for TFS 2018 Update 2 will be dropped on March 5th, 2019. All imports from this version will need to be completed before that date or you will need to upgrade your TFS to one of the still supported versions.

The TFS Database Import Service supports the two latest releases of TFS at a given time. Releases include updates and major releases. Currently the following versions of TFS are supported for import:

  • TFS 2018 Update 2
  • TFS 2018 Update 3, Update 3.1, and Update 3.2


The Import Service doesn't support imports from TFS release candidates (RC). If you're planning on importing your collection database to Azure DevOps Services using this service, it's important that you don't upgrade your production database to an RC release. If you do upgrade, then you will need to wait and upgrade to the release to web (RTW) version when it's available or restore a backup copy of your database from a previous TFS version to import.

Normal release cadence for new TFS versions is once every three-to-four months. Meaning that support for a given version of TFS for migration to Azure DevOps Services should last for anywhere between six-to-eight months. It's important to ensure that your planning accounts for this support window to avoid having to suddenly upgrade to migrate.

Preview Features


If you’re not including preview features when running TfsMigrator, then you will need to re-run TfsMigrator prepare to generate a new import.json to queue an import. You DO NOT need to include preview features when you re-generate your import.json.

If you had previously been including preview features then you DO NOT need to take any additional actions after Monday, April 23rd.

The following features can be included with your import, but are currently in a preview state.

When queueing an import you can elect to include preview features with your import. If you do, data related to these features will be copied into your new organization along with all your other data. Should you choose to not include these features then their data will not be copied.

For a list of items not included with an import please see the migration guide.

TFS Database Import Service Resources

In general you should use the migration guide when going through an import. When it's required the guide links back to the below documentation. These articles offer deeper technical knowledge on various import topics.

Importing Process



Q: Is there any risk of using the Hosting XML model becoming a problem in future updates of the service?

A: No, when it comes to service updates, Hosted XML organizations are treated the same as organizations using the Inheritance process model.

Q: Will my organization be stuck in Hosted XML forever?

A: You are using the Hosted XML process because the Inheritance process model does not contain all features yet. However, you can now clone a hosted XML process to an Inheritance process.

Q: Will migrating from Hosted XML into Inheritance process model be a manual process?

A: No, the migration is automated. Simply follow the steps to clone a hosted XML process to an Inheritance process.

Q: What happens in Hosted XML when Microsoft makes a change to a system process?

A: This is the same experience with TFS on-premises. If we make a change to a system process, it will not be applied to any of your Hosted XML processes. You won't have to update your processes if you don't want to. But if you do, you will need to make the changes in the XML definition files manually for each process.

Q: Is there a difference between a team project that was created manually versus one that was created from data import?

A. The features available to each team project are the same. The differences occur in how you modify the processes in your organization. When you create an organization, you will use the Inheritance process model to customize the work tracking experience. Team projects migrated via data import, however, will use the Hosted XML process model to customize the work tracking experience. As described above, these Hosted XML processes can be cloned to an Inheritance process model after import.

Q: If my organization is using Hosted XML, can I create new projects to use the Inheritance process model?

A: Yes. For data import organizations, Azure DevOps Services supports team projects that use Inheritance as well as Hosted XML process models. To learn more about the Inheritance process, see Manage processes.

Q: Where can I find more information on Hosted XML and the Inheritance process model?

Q: If I have feedback or additional questions is there somewhere I can reach out?

A: Yes, you can contact AzureDevOpsImport@microsoft.com. Please note that this alias is for general questions. If you need assistance with a failed import please contact VSTS\TFS customer support.