TFS Integration Platform – Snapshot … migrating only partial state

When you digest the guidance you quickly realize that the analysis of existing data, especially history, is an important link in the chain of a successful migration. Migrating history introduces complexity and more importantly time … if it took your organization 20 years to accumulate the history in terms of version control and work item artefacts, why should we expect the TFS Integration Platform to migrate everything in a 15min coffee break session?

  • With Version Control data we can select a snapshot of state (history) to migrate. See I have just moved my VC content, now I want to sync from a specific snapshot … now what? or the new TFS Integration Platform – Configuration document that will ship as part of the product in the next drop.
    • Options possible with VC today:
      • Complete history migration (not recommended)
      • Partial history migration
      • Snapshot migration (the latest and greatest only)
  • With Work Item data we do not have support for the snapshot feature as yet.
    • Options possible with WIT today:
      • Complete history migration, which includes the state changes.
    • What we are asking in this post ...
      • Should we support partial or snapshot migration for WIT as well?

Snapshots and selective history allows us to cherry pick what we feel is important and allows us to reduce the migration time of potentially lengthy migrations.

Therefore snapshots seem to be the way to go … or not?

Do you feel we need the feature supported for both WIT and VC, or is VC sufficient? Please add your candid feedback as a comment.

Comments (4)
  1. Dave Massy says:

    We definitely need to have snapshot migrations for both WIT and VC.

    WIT has tons of important history data that is in many ways more valuable,interesting, and important than VC.

    We've seen critical business decisions reflected in the history of our workitems. Like when we  prematuterly closed P1 bugs to make a ship date and had to ship 15+ critical fixes. It was expensive….people lost their jobs and we learned valuable valuable lessons about what not to too from the history of rushing a release…..I'd hat to have that type of data siloed on some TFS server and not be able to migrate it if we need too.

  2. Dave, if I understand you correctly you are saying that WIT history is more valuable and interesting and should be maintained. At this stage the platform support snapshot migrations for VC and selected/complete history migrations, whereas WIT only supports moving the history as well.

    What I am wondering is if there are teams that do not have your requirements, but instead only want the latest state of a work item to be migrated. In this case I would suspect, or suggest, that the original repository with the complete history is maintained for reference.

  3. Dave Massy says:


    When you mention "With Work Item data we do not have support for the snapshot feature as yet, for example to only migrate the latest WI state. " I think you mean that if we have a bug and it went from active to resolved, resolved to closed, in the current migration tool you only migrate the "closed" state and that the histohistoryry of active to resolved, resolved to closed is lost. Right? At first glance having a successful migration of the current state is great….but it misses that there may be extensive detailed information in the history of the state transistions. In our weekly release meetings we go through and read the comments with each state transition and determine if the righht call has been made, or if a "quick" decision was made that we don't agree with. We then as a commitee will write extensive comments as we change the state as we deem necessary. We've been looking into setting up seperate TFS servers for our different multi-year projects and if we need to consolidate 2 Team Projects at some point in the future the history of work item transitions will be very valuable. I don't know if you've solved the time compression issue or not (when all the dates change) but if you have then I think the answer you need is "Yes we need the feature supported for both WIT and VC".

  4. No, what I mean is that with VC we can select to migrate the complete history (not the recommended approach), partial history, or a snapshot in time. With WIT we migrate the history, whereby we have received some queries whether "snapshot" migration would not be a feasible feature, to be in a position to just migtrate the last state. While we currently migrate all state changes, migrating the latest state would loose historical state changes. I am gathering from the two responses to date that thedefault behaviour of migrating all of the hirtory for WIT is what is needed. I will update the blog post to clarify the default behaviour.

Comments are closed.

Skip to main content