Jaa

TFS-to-TFS migration

  • Artikkeli

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!

Comments

  • Anonymous
    November 18, 2007
    Brian Harry and Jeff Beehler outline the new TFS-to-TFS migration tool . Technorati Tags: Brian Harry

  • Anonymous
    November 20, 2007
    The Visual Studio Code Analysis Team Blog on Code Metrics as Check-In Policy and Code Metrics Customization....

  • Anonymous
    January 25, 2008
    This TFS-to-TFS migration tools seems promising. However, I doubt if it supports the scenario I have encountered: A project starts in TFS on location A and after some time that project must be migrated to another TFS on location B with NO connectivity between these locations A and B. TFS-to-TFS migration tool requires connectivity with source and destination from the tool, and the backup/restore works for an entire database, where it should be limited to only one dedicated project. Does anyone have ideas on how to solve this problem?

  • Anonymous
    January 28, 2008
    GBroek - Thanks for your reply.  I checked with our team that works on this, and it turns out we've helped other customers with a similar challenge.   Specifically, they followed these steps:

  1. Backup the TFS DB at location A
  2. Restore TFS DB at location B on a different machine (i.e. create another instance of TFS) 3. Perform the TFS to TFS migration at location B between the two instances The only challenge with this approach is that if the Active Directory is different between the two servers, none of the user IDs will match and so version control items will have a problem porting.  Do these servers share the same Active Directory domain?  Are you moving source code or just work items? Thanks, jeff

  • Anonymous
    February 02, 2008
    GBroek - I've followed up on the version control ID issues I previously mentioned and I've learned that it does not affect the source code history.  Instead, since the ID are foreign to the new system, there's no connection to the current set of users.  For instance, if I was looking for my checkins, I'd have to search under my old ID and my new ID to see the full extent of my changes.   Hope this helps! jeff

  • Anonymous
    June 02, 2008
    In addition to my day job of managing the next release of Team System, I have responsibility for both

  • Anonymous
    October 23, 2008
    We are a software vendor who has hired a 3rd party vendor to develop some of our software.  We are using TFS 2008.  They are considering using TFS as well for all of their software tracking needs (not just what they are working on for us).  If they move to TFS, we would like to send our TFS workitems that we want to assign them to work on and receive updates from those TFS items from them.  Could we use the TFS-to-TFS migration tool?  I believe from reading this the IDs would not be the same between the two but we should be able to link them to each other I assume so the updates will get into the correct workitems.  Also we would not have the same AD setup between the two offices.  Is there a better tool to use? Thanks for any info you have! Nicole

  • Anonymous
    March 02, 2009
    Hi,        We were using TFS 2005. Somehow our sys got crashed. We hav got the back up files of SQL db. We were able to restore it to TFS 2005. But when tried to restore to TFS 2008, we were able to restore it to db. We were able to make the WSS up. But when it came to RenameDT, error occured saying check whether the db is availabel. When tried to ActivateAT, one s was said to be missing. We are not able to proceed further. Kindly not that the tfs accounts for 2005 were different from 2008 and even the server name got changed. Any pointers wud be helpful Thanks in advance, Shyam

  • Anonymous
    March 27, 2009
    For error free TFS - TFS Migrations, try the 3rd-party tool Data Manager by OnePulse, Inc.

  • Anonymous
    October 15, 2009
    What does this tool do with Custom fields?

  • Anonymous
    November 17, 2009
    If I use TFS to TFS migration to migrate a single project from one TFS server to another,would it be possible to get the backup for that single project from destination TFS server.