TFS Integration Platform … YES, I can do a full TFS Server sync … but should I? Part 2

Injured Blue Man Sitting In The Emergency Room After Being Bandaged Up On The Head, Arm And Ankle Following An Accident Clipart Graphic In TFS Migration Tools: Should we opt for migration or synchronization? Part 1 we explored the first thought patterns that we should be creating when considering the TFS Integration Platform (TIP). In recent discussions at a Scrum course we discussed branching and the TFS Integration Platform during one of the breaks. I nearly choked and had a stroke when I heard the statement: “oh, so I can now do a full bidirectional sync of my TFS Server environment” … NO, please read on.

Here is an extract from our TFS Integration Platform – Migration Guidance document, as part 2 of the migration investigation and guidance initiative.


The synchronization scenario can help a “soft start” or gradual migration, such as a phased migration from one version of TFS to another version of TFS. As with the migration scenario you must “keep it simple” and decide how much history is relevant. Plan proactively and be aggressive when pruning the history to be synchronized and carefully consider the latency of delta computation, migration instruction generation and actual change migration.

Less is better! Simplicity Rules!

Synchronization Options

You have a number of synchronization options, including simple, multiple and full.

  1. Simple and stable synchronization of a single integration branch

    • It is important to keep the synchronization load down by reducing number of filter paths in mapping. Reconsider each TIP filter path carefully, confirming that the path & associated branch is (a) stable and (b) needed. If either (a) or (b) are no, probable or unknown, scratch it from the sync list.

  2. Multiple independent branches

    • … consider option 1 (simple) again before pursuing this avenue!

    • Feasible if one team (Dev-1) works on the target server and another team, Dev… works on the source server, with each team working independently and working off a stable and mirrored integration (main) branch.

  3. Full mirroring of all history and all branches
    … avoid this option at all cost! This is skull and cross bones country, with high complexity and maintenance costs.

… OK, I feel a little better now and hope that future break-out discussions will be less stressful 🙂

Comments (2)

  1. Max says:

    If the full mirroring of all history and branches using TFS Integration Platform is not recommended, what is the recommended solution for it then?

    Thank you!

  2. Hi Max, the TFS Integration Platform can be used to maintain a full mirror of WIT/VC data. This is a scenario that we have been dogfooding for some time as per Grant's blog posts (…/pioneer+dogfood). "BUT" … a full mirror of all history and all branches, in other words an ongoing bi-directional sync with full history, brings with it complexity and cost in terms of monitoring and maintenance. For example, if both sides are editing, you will have to deal with ongoing conflict resolution. The tooling includes monitoring features which will assist you, "BUT" you must be aware and prepared for ongoing maintenance.

Skip to main content