Monitoring TFS2TFS activity

Apr 28, 2009 at 2:27 PM
I'm migrating source code from a remote TFS to a local server.

It is going extremly slow (from 3 to 6 minutes each changeset).

How could I detect where is the bottleneck, or it is normal such a slow migration?

Thanks for your attention.
Apr 28, 2009 at 5:59 PM
Could you please provide us with the trace log for your session. Normally, it is generated to the installation directory of the migration tool. Please send the file to Thanks!
Apr 29, 2009 at 7:30 AM
It doesn't exist a trace log in the installation directory.
Apr 29, 2009 at 12:15 PM
I've made a profiling with ANTS Profiler.

It seems that the bottleneck is the authentication to the remote TFS server, ¿Does it make sense to you?

It expends quite a lot of time in TeamFoundationServer.EnsureAuthenticated. I send you a pdf with method tree to the provided mail.
May 6, 2009 at 7:11 PM
Edited May 6, 2009 at 7:13 PM

I have encountered the same problem. The source server is TFS 2005 server (no SP1). The target server is a TFS 2008 server (SP1). I installed the migration tool on another server which is 2003 server w/ SQL server installed locally. I am hesitating to install SP1 on TFS 2005 server because I don't know if that is absolutely necessary and any risks associate with the installation. Could this be my speed problem?

I started to migrate a big folder from TFS05 to TFS08. It took over 60 minutes and didn’t even finish the first change-set. So I stopped that session. I tried a small folder which contains only 4 files and no subfolders. It succeeded for the change set migration but it took about average 15+ minutes for one change set. That is extremely slow considering how small the change set is.


We have 74590+ change-sets and some of them are very big change-sets. Unless we can find out the bottle neck for this tool and improve the speed substantially, we can’t use this tool. I really hope that I can get some helps. Any suggestions or pointers are greatly appreciated.

May 6, 2009 at 7:17 PM
TFS 2005 (no SP1) is not supported by the tool. I am not typically involved in Version Conrol side of the migration tool. However, AFAIK, certain methods involved in branch/merge analysis are not implemented for Whidbey RTM. I guess this is possibly why your simpler VC migration scenario succeeded, yet the "full-scale" session involving branch/merge changes failed.

May 6, 2009 at 7:42 PM
Hi, Tony,

Answers to your questions:
1. TFS 2005 (no SP1) is not supported by this pre-release of migration tools. You will get an incompatibility error when you start to migrate a merge change. Your test changeset may contain no merge change, so it completes without problems. But you may encounter this problem for your large migration. So please upgrade to SP1.

2. Performance issue - there is a known performance bug of the current pre-release of migration tools. It may apply to your situation. On a large TFS system, there may be thousands of changesets. Although you only map a specific folder for your migration. The migration tool still need to check each changesets to see whether it contains changes mapped.

In your case, if you create the small folder on the same TFS server, it may still go through all changesets until it starts processing the small folder. That's why it takes 15+ minutes to migrate 4 files. You can verify this by migrate 2 consecutive changesets. The 2nd changeset should take less than 1 minute to migrate. 

However, for a TFS system where changesets to be migrated are not very sparse, this shouldn't be too much a problem.

We already have a fix for the performance bug mentioned above. I hope to port the changes to codeplex source tree within two weeks.