TFS Integration Tools – How long will it take to migrate X GB VC/WIT data?

  • Article

The bad news is that the answer should come at no surprise … “it depends”. Here is some information I have consolidated to date for the TFS Integration Tools (Platform) during discussions with teams who have or are using the tooling. A special thank you goes to Thorsten Dralle and Adam Jagocki for their feedback.

“Rough” Estimates

For Work Item Tracking (WIT) data, the planning poster offers a rough guidelines to work out a “rough” estimate:

  • Delta Computation: 400 revisions/min
  • Migration Instruction Generation: 350 revisions/min
  • Change Migration: 120 revisions/minTIP_Timing_0

For Version Control (VC) data, the planning poster is anaemic, whereas the migration guidance document mentions “rough” estimates we gathered during dog fooding exercises:

  • Rough Change Migration: 600 revisions/min.
  • Estimates for specific actions which have been mentioned from in-the-field migrations:
Operation Seconds
Add 0.103
Merge 0.384
Rename 0.116
Delete 0.147
Edit 0.123

Why is it so difficult to come up with “rough” estimates?

The migration duration depends on the amount of history you are planning to migrate, the complexity of the data and relationships, the infrastructure you use to host team Foundation Server, SQL Server and the TFS Integration Tools, the migration adapters and many other cogs and wheels, such as authentication.

  • Latency is the major contributor to time, because during the migration the tools have to literally replay every single action. This is important to remember when you are considering to migrate data that you have literally accumulated over years and possibly decades.
  • With version control TFS does not have any bulk operations for VC and as a result every single step has to be pended, resulting in a lot of calls and round trips.
  • Based on feedback from the field
    • The migration phase is about twenty (20) times slower than the analysis phase. It is not uncommon to see the analysis phase run for days with a substantial amount of historical data.
    • About 10 change actions (items) can be processed per second for a normal change group with multiple items.
  • Thorsten Dralle  highlighted another major latency contributor when TFS cannot resolve the identity. When this exception occurs the TFS Integration Platform retries the operation using the identity running the migration, which results in a second round trip, double execution and therefore double latency.

What should you do when planning a migration?

The recommended way is for you to take a slice of your operational environment and associated data and use it to perform a proof-of-concept prototype in a controlled environment. This allows you not only to determine a rough estimate for your data, but also ensures that you are able to fine-tune the WIT mappings and the migration configuration before running the migration in your production environment.
TIP_Timing_1… extract from migration planning poster.

What’s Next?

We are continuing to collaborate with migration specialists and partners using the tools to try and come up with the magic formula. However, it is very unlikely that we will ever come up with an easy to understand and apply formula, which means that the migration proof-of-concept (POC) prototyping is key to the success of migrations in your environments.