As more and more people are using TFS, we have been hearing requests to help customers migrate Team Projects from one TFS server to another. Several scenarios are common including:

• moving a single project from one TFS server to another
• consolidating projects from separate TFS servers on to a single server
• mirroring elements of a team project between two separate locations

In support of these requests, the Team System Rangers have created a migration utility aptly called the TFS to TFS Migration Tool.  We've heavily leveraged the TFS Migration & Synchronization Toolkit along the way (which in itself was a good test of the toolkit).  However, it's important to note that this approach has some limitations (which are also outlined on the associated Codeplex site):

1. This tool is only capable of copying Version Control items and Work Items, and links between them. It does not bring over reports, Team Build history, Sharepoint content, or any of the other portions of a Team Project.
2. Work Item id's and Changeset id's will always be new in the target project. This can create confusion when folks refer to ID's in bug descriptions and other places. When Linking is leveraged, the ID’s for the new changesets are reflected.
3. Timestamps will be lost when using this tool, all creation times for work items and version control operation times (add, edit, delete, branch, merge, etc) will reflect the time that the migration was performed. This will effect reports that rely on a time dimension.
4. Version Control migration is complex. This is just the nature of the beast. When actions are performed in TFS, not all of the information is stored (i.e. the order that changes were pended on a set of items). When the migration tool tries to “replay” these actions, it may not have enough context into the operations that were performed to automate the migration correctly. As a result, some situations with complex sequences of actions may require manual work-arounds before proceeding with the automated migration.

For some related scenarios, there are alternative approaches that you might want to consider evaluating alongside the possibility of using the Migration Tool:

1. Backup and Restore may be a better option when IDs and timestamps must be preserved. This process is well documented on MSDN.
2. Upgrading from TFS 2005 to TFS 2008 can be handled by the upgrade functionality in the product, this tool does not need to be used.
3. If you are looking to move an entire server or a subset, keep in mind that you can do a backup restore, and use the new Team Project Delete functionality in TFS2008 to remove unwanted Team Projects. The new ‘Destroy’ feature can also permanently delete version control items.
4. For remote site development, consider using Team Foundation Proxy before considering this tool, this functionality works out of the box and is a well worn path.

If these limitations are acceptable to you, I'd certainly recommend investigating this new tool. And if you do, please let us know what you think and how well it works for you. 

Brian Harry also wrote a good introduction to this tool if you want to learn more.

Congratulations to the Rangers for another successful release aimed at helping overcome adoption hurdles for Team System.

Woohoo!