Migrating Azure boards

[Lokeshmaxi]

Migrating Azure boards
i have couple of questions which required clarity?

For example: my source org,project name is DEVOPS_TEST and my target org,project name is DEVELOPMENT_TEST

1)I have used workitemmigration processor for migrating workitesm,links,attachment and history

Errors faced while doing migration

a) if source project name and target name is different, how to do nodestructure mapping tool for these scenario?

b) instead of using TFSnodestructure tool and tfsteamsettingsprocessor, we can use workitemmigrationprocessor alone for creating node iteration and area,migrating teamsettings and migration of workitems right?

c) while migrating Shared Queries i got error for some of queries such as ,

1. add or subtract operators can only used with dates or numberical constants,error caused by @currentiteration -1
2. what if in one of query have used another project area path in input? how to resolved this?

e) how to migrate column options in Boards?

f) if we not using configured fieldmapping, will create by default while running workitemmigrationprocessor?

g) if we migrating bulk workitems say for eg: 14000 counts which consist of multiple workitem types,along with child/parent link as well, it is ok to do migration on batch wise first 5000 counts by workitem id count in asc order or we should migrate by workitemtype wise or bulk migration in single go ? if single go is good option? how to tackle same for counts above 20000 counts of total workitems?

h)during the migration of workitem, if processor stopped/killed , when i rerun the processor with filterworkitemthatexistareexistintarget: true, why it is validating from the beginning?

i) if a user is commented with taging workitem id or link in source, once migrated it will preserved but cannot be accessed/used right? since if we migration of exact workitemid from source is not possible by azure devops.

[MrHinsh]

Id direct you to the docs https://devopemigration.io with the following additions:

if source project name and target name is different, how to do nodestructure mapping tool for these scenario?

Thats automatic. check Tfs Node Structure Tool

nstead of using TFSnodestructure tool and tfsteamsettingsprocessor, we can use workitemmigrationprocessor alone for creating node iteration and area,migrating teamsettings and migration of workitems right?

All of the tools run as part of the processor runs, they can be run alone.

add or subtract operators can only used with dates or numberical constants,error caused by @currentiteration -1

Yup, this does not work and you cant migrate those quires

what if in one of query have used another project area path in input? how to resolved this?

Its automatically mapped and honors the Tfs Node Structure Tool

how to migrate column options in Boards?

Manually, we don't have a migration for board columns

if we not using configured fieldmapping, will create by default while running workitemmigrationprocessor?

I don't understand this... but all fields that are the same are mapped. All fields that are not the same need a mapping configured.

if we migrating bulk workitems say for eg: 14000 counts which consist of multiple workitem types,along with child/parent link as well, it is ok to do migration on batch wise first 5000 counts by workitem id count in asc order or we should migrate by workitemtype wise or bulk migration in single go ?

yes

how to tackle same for counts above 20000 counts of total workitems?

batching

during the migration of workitem, if processor stopped/killed , when i rerun the processor with filterworkitemthatexistareexistintarget: true, why it is validating from the beginning?

I don't understand the question

if a user is commented with taging workitem id or link in source, once migrated it will preserved but cannot be accessed/used right? since if we migration of exact workitemid from source is not possible by azure devops.

This also makes no sense, can you rewrite.

[Lokeshmaxi]

Thanks for respone @MrHinsh

1. when i was running workitemigrationprocessor , due to some issue , it got stucked / stopped inbetween migration , when i reran the processor with this attribute filterworkitemthatexistareexistintarget: true in workitemmigrationprocessor, it is takes more time to complete for count of 5000 total workitems? is this expected or what is the best pratice if we encounter processor got stuck or stopped ?

2. For eg "task" is migrated to target organization , it will be migrated with new workitem ID , but when user is commented in any workitem using same workitem with old workitem ID in comment history, that will not be changed to new workitem id right?

3. how to preserve Workitem exact creationdate and preserve history?

4. If we do batch wise for bulk migration,if first batch one workitem have one child workitem , which will be migrated in next batch? how parent/child is properly linked ?

[MrHinsh]

when i was running workitemigrationprocessor , due to some issue , it got stucked / stopped inbetween migration , when i reran the processor with this attribute filterworkitemthatexistareexistintarget: true in workitemmigrationprocessor, it is takes more time to complete for count of 5000 total workitems? is this expected or what is the best pratice if we encounter processor got stuck or stopped ?

When enabled it also loads the work items that match the same query from the target project and removes any completed iterations from the source data. This takes time to compute..

The alternative though is that we just process every work item again, which in usually a higher cost as it required many calls to the target to verify each element as we go.

For eg "task" is migrated to target organization , it will be migrated with new workitem ID , but when user is commented in any workitem using same workitem with old workitem ID in comment history, that will not be changed to new workitem id right?

Correct we do not update comments in work items or code.

how to preserve Workitem exact creationdate and preserve history?

This is best effort and the default. We preserve what we can.

If we do batch wise for bulk migration,if first batch one workitem have one child workitem , which will be migrated in next batch? how parent/child is properly linked ?

It just works since links can be created from either end.

[Lokeshmaxi]

Thanks @MrHinsh