We have an existing TFS 2012 installation with multiple project collections and want to ultimately move to TFS 2017. We have a new TFS 2017 server installed on new hardware/latest version of SQL Server. We would like to move our project collections from 2012 to 2017 while maintaining as much fidelity to the old server as possible (maintain source, work items, history, linkages, etc...)

Can this be done one project collection at a time, or does it have to be "big bang"? All my research so far has shown instructions of copying the old TFS 2012 database to the new database server and allowing it to upgrade the collections from there, but that sounds like a scenario where 1) you have to move all collections at once, and 2) would overwrite any collections that may have been set up in the new TFS 2017 instance.

Is that correct, or is there a high-fidelity way to migrate that would allow us to do it one collection at a time?

FYI-We are not concerned about reporting or Sharepoint migration, only work items, source, and maintaining the history of changes to both.

1 Answer 1


Yes, you can.

Upgrading one Collection at a time is not recommended for the following reasons:

  • it is the less trodden path, so you may encounter unique problems;
  • detaching a TFS collection is a risky operation (I had to escalate to MS Support in some cases especially for TFS 2012).

Another option for you, requiring more time and resources but safer, is to use a staging TFS instance used for migration purpose. The idea is to replicate the existing 2012 (I do not use clone because it is dangerous), installing the same version of SQL and TFS, restore your backups, configure TFS 2012 (this is the most dangerous step, use different accounts etc.), finally upgrade to the same TFS 2017 version you will use in production. At this point, you can detach a collection from staging and be sure it will attach to production without issues.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .