1

we are migrating from TFS 2010 to Visual Studio Online. Our biggest Team Proyect has 14k ChangeSets. We are trying to migrate but based on the current "speed" it would take about 18 days to migrate.

I now there is a similar thread but:

Slow TFS migration from on-premise to TFS online with OpsHub tool

but it does not provide a solution. So I'm asking for help.

For TFS 2010 we have one Application Tier Server, a Database Tier Server.

Both Servers are performing ok (Memory, CPU,Network) during the migration

We are launching the migration Utility from a differect computer which also has ok performace (Memory, CPU, Network)

But in 12 hours, only 400 changesets has been migrated.

We are using version 1.0.1.008

Thanks in advance

Community
  • 1
  • 1
Christian Rodriguez
  • 944
  • 1
  • 9
  • 20
  • Hi Christian, Can you provide us with a deeper insight on your changesets. -How many files does a typical changeset on your environment contain? -From those number, what percentage of files are binary files? (Executables, Libraries, Media etc) -Rough size (in terms of disk space) of a typical changeset? -How complex are your merges-branches? Multiple branches/merges in a single changeset? -Do you have overnight builds? Which would denote that a significant number from the 14k total count would be labels. – OpsHub Inc. Nov 07 '14 at 07:18
  • We normally don't use labels at all, meaning that all TFS created labels are "expendable". A tipical changeset can contain 1-30 Files, normally 90% of code files (c#, javascript ,etc), and other 10% images. Actually changesets normally only include code files, and very seldom images. We branch every release, Merging from Dev -> Main -> New Release. Once the new release is stabilized and Bugs merged from release, we don't do much merging until next release (we releas each 4 months). Does this information help? – Christian Rodriguez Nov 07 '14 at 08:42
  • We have a Dev - Main - Relase X branching strategy. We normally develop at Dev Branch. Our Branch has now about 13.800 files. We have multiple CI Builds, including nightly builds. – Christian Rodriguez Nov 07 '14 at 08:44
  • Also maybe 5-10% of the changesets include .dll's (third party libraries / frameworks) – Christian Rodriguez Nov 07 '14 at 08:48
  • Update: We had a significant amount of TFS created labels (Builds). I've deleted them all and now we have 13K changesets. The process it's still very, very slow. – Christian Rodriguez Nov 07 '14 at 12:58
  • Hi Christian, can you zip and send us the logs located at /logs to ovsmu@opshub.com and we'll analyze them to decipher which activity is consuming more time. Thanks – OpsHub Inc. Nov 10 '14 at 05:44
  • Alright I just sent you the logs. – Christian Rodriguez Nov 10 '14 at 12:49
  • Any update? Have you found any issue in the logs that I sent you? – Christian Rodriguez Nov 13 '14 at 11:08
  • How big is your TFS databases? Total? – MrHinsh - Martin Hinshelwood Nov 13 '14 at 15:21
  • @MrHinsh thanks for your concern, but I'm posting in StackOverflow because it is the official way to contact the opshub team. – Christian Rodriguez Nov 13 '14 at 15:48
  • @ChristianRodriguez we are checking log file, and update you in mail for further query, also once we will find something , we will also update as answer/comment here. – OpsHub Inc. Nov 14 '14 at 13:05

2 Answers2

4

Update from OpsHub.

We have done major performance improvements in the current release. It would be available to public by the end of this week.

Thank you Christian for your assistance in this case.

OpsHub Inc.
  • 1,095
  • 1
  • 6
  • 13
  • 1
    Just to confirm. I was using 1.1.0.001 yesterday and got around 60 changesets per hour. Upgraded to 1.1.0.005 and restarted the migration and I get around 400 changesets per hour now. – Gunnar Steinn Dec 19 '14 at 13:00
  • Yes the performance of the tool has been vastly improved. Many thanks to the OpsHub team for their support – Christian Rodriguez Jan 16 '15 at 14:12
0

A rule of thumb is that it will take as long to migrate your history as it took to make it in the first place and those times are not outside the bounds of reality. I would ditch the history and move just the tip.

Clarification: No that is not slow that's just how long it takes to do migrations.

If you have a lot of modifications to code and or work items then it will take a very long time. You can make things faster by throwing processor at your source server and sticking a fat pipe in the way, but you are network bound.

You could spin up an Azure server in the same data center as your target VSO and install and configure your TFS 2010 environment there. Then run the migration. That will be much faster, and will still take a long time.

MrHinsh - Martin Hinshelwood
  • 23,409
  • 5
  • 46
  • 69