What's that you ask and why would I want it?

As you know TFS stores a ton of lifecycle data about application development - source code, change history, tasks, bugs, historical data, ...  If you use the TFS client tools, all of that data goes in and comes out of TFS very nicely.  However, there are lots of scenarios where that isn't quite what you want.

The first set are around "legacy systems" and involved questions like.

  • "Today, I use X and I want to use TFS.  How do I transfer my source code, bugs, etc with history from system X into TFS?"
  • "My company previously standardized on X but we really want to try TFS for a new project.  How do we use TFS but still get all of our data (source, work items, etc) into the existing system?"
  • "We use Y for IT help desk management and we'd really like to hook up our development issue tracking system to it.  How do we do that?"

To help answer these kinds of questions, we built something called the TFS Migration & Synchronization Toolkit.  This toolkit helps you build tools that let TFS interoperate with other systems either in a unidirectional or bidirectional way.  On top of that we've been building (and working with partners to build) tools for specific systems - like the ClearCase migration and synchronization tool.

In parallel with this we've had another set of customer requests that have nothing to do with other products.  They tend to be of the form...

  • "I've got a project on my TFS server that I want to move to another server, how do I do that?"
  • Or a variation - "I've got 2 TFS servers that I'd like to consolidate, how can I do that?"
  • "We've got a server in Bangladesh and a server in New York and an unreliable network between them.  How can we have local copies of everything in each place and replicate the data back and forth whenever the network connection happens to be up?"
  • and other related examples.

In the long run, some of these scenarios are best served by direct support in the product and we are working on that for our Rosario release.  However, in the mean time, it occurred to us that you can view these very much like the "product X" scenarios above with product X just being another TFS server - and hence the TFS to TFS Migration Tool was born.

This tool is delivered on Codeplex with source code (see the link in the last paragraph).  It enables:

  • One way migration of TFS source code and work items from a project on one TFS server to a project on another TFS server.
  • Bi-directional synchronization of TFS source code and work items between a project on one server and a project on another server.

Lest you become too giddy at the prospect, it is not a perfect solution and some of the limitations of this approach make it less than ideal for some of the scenarios I listed above.  Here are some of the key issues to think about when deciding how to use this tool:

  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 different in the target project 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 - particularly when doing bulk one-time migrations; less so when used for continuous bi-directional synchronization.
  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.

In addition to helping address all of the scenarios listed above, it fulfills one additional valuable purpose - it is a fantastic sample of how to use the TFS Migration Toolkit to build a high fidelity tool to integrate TFS with other systems.  This is something that has been sorely lacking since we first released the toolkit.

We've already used to this tool successfully with several customers to accomplish the kinds of scenarios I described.  However, it's still fairly early and don't expect the ride to but completely bump free yet.  You've got the source code so you can fish for yourself or you can contact us through the Codeplex project site and let us know about any problems you have and we will do our best to help you.

Enjoy and good luck with it!  Let me know if you have any successes or failures.

Brian