Migrating WorkItems and Version Control - no linked Changesets?


  • We have a TFS 2010 server with 1 main TFS Project and ~10 very small TFS projects, all in the same collection.  Per these recommendations we want to migrate the 10 small projects into our main Project.  We explored accomplishing this with TFS Integration (in a sandbox environment).  The Work Items migrated fine.  (Well, in our first test project there was only 1 Work Item.)  Then the Version Control migrated fine.  However, the 5 Changesets were not linked to the migrated Work Item.  Any ideas why this might happen?  I didn't see anything obvious in the logs.
    Wednesday, August 29, 2012 4:35 PM

All replies

  • Hi bcoll,

    Thanks for your post!

    Please be aware of the Limitations that exist for this platform, as outlined on the following:

    What IS NOT migrated by the Toolkit

    • Check-in notes
    • Labels
    • Permissions
    • Workspaces
    • Pending Changes
    • Shelvesets
    • File encodings
    • Subscriptions
    • Test Cases
    • Check-in policies
    • Reports
    • Team Portal / SharePoint
    • Process Templates
    • Work item queries
    • Builds
    • Warehouse data

    For more information, please refer to

    Hope it helps!

    Best Regards,

    Cathy Kong [MSFT]
    MSDN Community Support | Feedback to us

    Friday, August 31, 2012 7:08 AM
  • Hi bcoll,

    I marked the reply as answer, if you have any concern with it, please feel free to unmake it and let me know.

    Best Regards,

    Cathy Kong [MSFT]
    MSDN Community Support | Feedback to us

    Monday, September 10, 2012 6:27 AM
  • Hi, apologies if I'm missing something, but this isn't helping me.  The small test project consisted of 1 work item, which had 5 linked changesets.  The work item and changesets migrated, but the links did not.  The links are supposed to migrate - at least that's my understanding.  I tried a different test project that was a little larger, and most (if not all) of the linked changesets did migrate.  One potentially interesting aspect with the problem is that all 5 changesets involved at least 1 file rename or file delete.
    Monday, September 10, 2012 12:59 PM
  • Hi,

    Did you migrate source code and WIT in the same TFS integration session ?

    Could you explain the mapping you've done for source code between source & destination team projects ?

    Tuesday, September 11, 2012 7:21 AM
  • Yes, I chose the the standard Source Control & Work Items (one-way) option to migrate everything at once.

    Regarding source control:

    Source: $TfsProjectA\

    Destination: $TfsProjectB\FolderA

    All of the files in the changesets resided in TfsProjectA\...


    Tuesday, September 11, 2012 3:27 PM
  • Well ... I have an "unofficial answer" :

    I just reproduced this behavior with a complex migration. (WIT mapping fields, complex branch schema...)

    And that's right :

    At the end of the session, WIT and changesets were not associated.

    I had to launch it again to "finish" the association.

    I don't understand why it does not happen on a "simple" migration with basic source code & WIT.

    • Proposed as answer by akam74 Wednesday, September 12, 2012 3:05 PM
    • Marked as answer by bcoll Tuesday, September 18, 2012 1:04 PM
    • Unmarked as answer by bcoll Friday, September 21, 2012 10:06 PM
    Wednesday, September 12, 2012 3:05 PM
  • Hi bcoll,

    So, did you try to launch again TFS Integration after the end of your session ?

    Is the association changeset/WIT now kept?


    Tuesday, September 18, 2012 12:31 PM
  • That was it - thank you!
    Tuesday, September 18, 2012 1:04 PM
  • Hi,

    So I have an update... after applying this workaround to our test environment and seeing positive results, I ran the migration in our production environment.  Once again the linked changesets did not migrate.  Unfortunately this time clicking Start again did not correct the issue.  (I even tried it about 5 times but I've been told that's the definition of insanity. :-) )  Again there's nothing that stands out to me in the logs.  One Work Item had an External Link Count of 23 at the source, and this was the matching log entry in TFS Integration:

    [9/21/2012 5:07:56 PM] TfsMigrationShell.exe Information: 0 : WorkItemTracking: Generating linking delta for non-Work Item links for Work Item: 16594
    [9/21/2012 5:07:56 PM] TfsMigrationShell.exe Information: 0 : WorkItemTracking: Detected 23 non-Work Item links for Work Item '16594'

    I don't see anything after that to indicate success or failure.

    Friday, September 21, 2012 10:06 PM
  • I believe the problem is related to branches.

    In the past the following happened:

    Added stuff to $\TfsProjectX
    Moved from $\TfsProjectX to $\TfsProjectA\A.00.00
    Renamed $\TfsProjectA\A.00.00 to $\TfsProjectA\Main
    Branched Main to $TfsProjectA\A.00
    Did a bunch of development
    Ran TFS Integration to migrate the data to $TfsProjectB\FolderA\[Main, A.00, etc.]

    If I create a test file at $TfsProjectA, the file, the workitem, the changeset, and the link between the work item and changeset all come across successfully.

    If I create a test file at $TfsProjectA\A.00 or $TfsProjectA\Main, the link does not migrate.

    During the migration I received conflicts because TFSIntegration didn't know about $\TfsProjectX and $\TfsProjectA\A.00.00.  In these cases I always resolved by Add New.  Could that have created this bizarre side effect?

    Does anyone know how I can fix the issue?  Thanks in advance.

    Saturday, September 22, 2012 8:53 PM
  • On which path did you run the migration ?

    $\ ?

    If you ran the migration on a branch, I guess you face this issue :

    In my case, I got the best results when I migrated all the source code hierarchy and permanently deleted the old branches.

    "Old branches" = deleted or renamed branches.

    • Proposed as answer by akam74 Sunday, September 23, 2012 6:38 AM
    Sunday, September 23, 2012 6:38 AM
  • Thanks for your help Akam74!  The tool migrated from $\TfsProjectA. to $\TfsProjectB\FolderA.

    It's unfortunate that the TfsIntegration tool lost the links to the changesets.  It certainly seems related to the branch stuff, even though 95% of the changesets occurred after the branches were converted to Add New.  There's really no reason for it as far as I can tell.

    Because I didn't want to permenantly delete the branches and renames (in the event this exercise became a failure, I want something to go back to), and because I didn't want to re-run the migration and have more duplicate code and work items, I opted to write a tool to re-link them myself.

    To match source work items with destination work items, I matched on fields such as Title, etc.  To match the source changesets with the destination changesets, I leverage the fact that the source changeset is burned into the destination changeset's comment by TfsIntegration. [string delimiter = @" (VC)' Id: ";]

    Tuesday, September 25, 2012 2:20 AM
  • Sample tool logging:



    29227 [36057]: 56631 [72310],
    29235 [36058]: 56663 [72312],
    29347 [36059]
    29587 [36060]: 57505 [72321],
    29652 [36061]: 57639 [72327],
    29983 [36062]
    30555 [36063]
    30556 [36064]
    31134 [36065]
    31173 [36066]: 62236 [72383], 62235 [72382], 62231 [72378], 62095 [72375],
    31490 [36067]
    31507 [36068]: 62234 [72381], 62233 [72380],
    31508 [36069]
    31509 [36070]: 72459 [72476],
    31510 [36071]: 62232 [72379], 62230 [72377],
    31575 [36072]: 62603 [72396], 62602 [72395], 62420 [72386],

    Tuesday, September 25, 2012 2:22 AM