VSTS to VSTS Migration is skipping over all Links and Attachments about azure-devops-migration-tools HOT 17 CLOSED

It was sillier than that, I was going from Scrum to Agile and my query contained User Story instead of Product Backlog Item and I was not linking Impediment to Issue.

from azure-devops-migration-tools.

Let take one as an example for debug:

LinkMigrationContext: Migrating Links for wiSourceL=5177
LinkMigrationContext: Cannot find twiTargetL matching wiSourceL=5177 probably due to missing ReflectedWorkItemID

Can you open up your target location in a browser and create a query that looks for 5177 in the ReflectedWorkItemId field?

What it looks like is that the field "ReflectedWorkItemId" does not exist in the target location, and thus there is no way for the tool to find the migrated work items.

from azure-devops-migration-tools.

Just attempted and it does not exist on the target or source.

from azure-devops-migration-tools.

You need to add that field to the target before you do a migration. This field will be populated with the ID from the old system and will be used by the other migrators to map your links and attachments from your source to the target.

Effectively what you migrate the links it will take the original source ID and look it up in the ReflectedWorkItemId of the new target location. If it finds a match for both ends of your link then it will add them.

Without the ReflectedWorkItemId field containing the source work item ID there is no way to migrate links or attachments.

from azure-devops-migration-tools.

understood and I have attached a screenshot of the field on the target. All of my work items have the ReflectedWorkItemId field.

from azure-devops-migration-tools.

Sorry, I thought that:

Just attempted and it does not exist on the target or source.

Can you then search for 5177 in that field? if it returns then we have a bug... somewhere...

from azure-devops-migration-tools.

Like so?
This query has been run with zero results on both the target and source.

from azure-devops-migration-tools.

ok, so that work item has not been migrated to the target.

If you look it up on the Source what is the work item type?

from azure-devops-migration-tools.

It is a User Story.

from azure-devops-migration-tools.

We're any of your User Stores migrated? There is no left hand side for WorkItemTypeDefinition that is User Story.

from azure-devops-migration-tools.

So I did a bit more digging and came to the conclusion that the reason those item ID's were not migrating is due to the fact that they have previously been migrated from TFS to VSTS which is somehow making them unable to be migrated again. anything created new in VSTS with attached links and files migrates fine minus the area path being removed.

from azure-devops-migration-tools.

@jaw2ay make sure to set the reflectedworkitemid field back to “” if some items were already migrated and you want to migrate again. Use a query + bulk editing

from azure-devops-migration-tools.

@MrHinsh If a Work Item is linked to another parent Work Item that is not in the scope of the query, it seems that I am losing that child Work Item in the migration. Is it safe to assume that this is correct? I am running a query on TFS that states I have 55k Work Items yet when I migrate I am left with around 16k Above epic is a custom work Item named Release that most work items are associated with in a Parent child way. I have not created a Release Work Item template on VSTS and I can only assume that this is my problem. Can you confirm this for me?

from azure-devops-migration-tools.

No this is not the case.

The WorkItemMigration does not look at links or attachments. Simply at what is in scope based on the query specified in QueryBit.

It should say, "xxx work items found" just after it starts the migration.

from azure-devops-migration-tools.

Can you share your QueryBit?

from azure-devops-migration-tools.

Sure it is just based on your sample that omits closed work items.
Sent the whole processor just to make sure I am doing this right.

{
"ObjectType": "VstsSyncMigrator.Engine.Configuration.Processing.WorkItemRevisionReplayMigrationConfig",
"Enabled": true,
"PrefixProjectToNodes": true,
"UpdateSoureReflectedId": false,
"QueryBit": "AND [Microsoft.VSTS.Common.ClosedDate] = '' AND [ReflectedWorkItemId] = '' AND [System.WorkItemType] IN ('Shared Steps', 'Shared Parameter', 'Requirement', 'Task', 'User Story', 'Bug', 'Feature', 'Test Suite', 'Test Plan', 'Test Case')"
},

from azure-devops-migration-tools.

You should remove Test Plan and Test Suite as there is no value in migrating them. New ones will be created by the Test Migrator.

Since you are omitting closed work items I would guess that's where the bulk of the missing items are...

from azure-devops-migration-tools.