Migration Batch Size?

[carsonholmes]

I'm so excited to have this application running, much appreciate the community! I started it running on a batch of 7500 work items about three hours ago. The first 1000 seemed like good performance but it seems like the more it runs the slower it gets, as if it's looping through the batch size each time to generate links.

If I break up the batch in random chunks, do the links properly migrate? If not, I guess Epic trees would be the best approach, though I may lose linking across those trees. Appreciate any guidance here. Thanks!

[MrHinsh]

Yes, if you break it up all the links will work. The state for the migration is stored in the "ReflectedWorkItemId" field and its resumable and choppabl-uppable!

You can use a query to chop it up into batches.

I don't think that the lower speed that you are encountering is to do with the batch size.

• Number of revisions, attachments, links - Links are created only for work items that exist, so early on in the migration there are less links are created. They are then added with the later work items. In addition, the order of the migration may be impacted as older items may have a different profile for number of revisions or links.
• Rate limiter - Azure DevOps will protect itself if you are making too many calls. You can use /_settings/usage to see if you are hitting the limits and how the limits are applied. You just need to take it, or spread the migration over multiple runs.

I hope that helps!