On-Prem Work Item Migration Not using Dummy Work Item for Embedded Images

[SteveSims2]

My main collection backup size gradually grew to a point where we decided to migrate the most recent "living" (not-dead-code) projects over to a new collection on a test server. We are also converting to git using git-tfs. This post is only about our work item migration using the devopsmigration tool.

After using the tool and seeing how well it worked, I wanted to "orchestrate" the move of the last year of work items to my test server collections (we only use one project for work items for the entire source collection). So I created a powershell script to create a lot of "dummy" work items in a "dummy" project in order to increment the work item number to my starting point. The goal was that I wanted the work item numbers in my source to match the work item numbers in the target for the latest 26,000 (one years worth) of work items.

Everything worked fine until the tool decided to create a dummy work item for embedded images in the target. I tried various configuration changes to avoid that, but nothing worked. Eventually what DID work was pulling the source and changing the code in TfsEmbeddedImagesTool.cs in the MigrationTools.Clients.TfsObjectModel.dll to never create them.

I only changed UploadImageToTarget like this:

        private Microsoft.TeamFoundation.WorkItemTracking.WebApi.Models.AttachmentReference UploadImageToTarget(WorkItem wi, string filePath)
        {
            var httpClient = ((TfsConnection)_processor.Target.InternalCollection).GetClient<WorkItemTrackingHttpClient>();

            // Upload and create the image attachment
            Microsoft.TeamFoundation.WorkItemTracking.WebApi.Models.AttachmentReference link = null;
            using (FileStream uploadStream = File.Open(filePath, FileMode.Open, FileAccess.Read))
            {
                link = httpClient.CreateAttachmentAsync(uploadStream, fileName: Path.GetFileName(filePath))
                                 .ConfigureAwait(false)
                                 .GetAwaiter()
                                 .GetResult();
            }

            if (link == null)
            {
                throw new Exception($"Problem uploading image [{filePath}] for Work Item [{wi.Id}].");
            }

            // --- Removed dummy work item creation and patching ---
            // Originally, the code would:
            //   1. Retrieve a dummy work item (GetDummyWorkItem)
            //   2. Add the attachment to that dummy work item via a JSON patch
            //   3. Then remove the relation so that the dummy work item is cleaned up.
            // We are simply skipping that step and returning the attachment link.

            return link;
        }

Note the comments.

Please understand that in all of my source work items there were only 3 work items with embedded images, and all of those were in the revision history of these items. And even if I choose not to replay history, or even if I attempted migrating a section of history that did not contain ANY embedded images the tool created the dummy item anyway, which threw off the target work item numbers by one each time.

But this modification seems to have accomplished my goal. My question is: For the 3 items with embedded images in their revision histories, what should I expect to not be functional as a result of my commenting out the above code?

SteveSims

[MrHinsh]

We do not support maintaining the ID of the work items across migrations in any way.

My question is: For the 3 items with embedded images in their revision histories, what should I expect to not be functional as a result of my commenting out the above code?

The image links will still point back to the original organisation. All this code does is download the images from the source, upload them to the target through the temp work item, and then update the link in the comment / description.

---

Why not turn that tool off? Was the flag not working? As per TfsWorkItemEmbededLinkTool you can turn it off with:

{
  "MigrationTools": {
    "Version": "16.0",
    "CommonTools": {
      "TfsWorkItemEmbededLinkTool": {
        "Enabled": "False"
      }
    }
  }
}

[SteveSims2]

I believe I knew that already. I just didn't know that you might not attempt to answer a friendly question about that code I removed, since I got it working by myself anyway. While I know the code I removed had some value, I could not discern what that value was. Just thought I would ask. Feel free not to answer if it violates your intentions not to support this "in ANY way". I will eventually figure this out by myself also.

[MrHinsh]

I did not see your question. Updated above

[SteveSims2]

Ah, ok, thanks MrHinsh. Once we "go-live" and make the switch, then these 3 old work items probably won't display these embedded images anymore. That's perfectly fine for our needs. We just have so many business organizations around the world that keep the actual numbers to old stuff for research purposes, the value of doing this orchestration far out-weighed the need for a few embedded images to work. I appreciate that however large we might be in terms of organizational size that this might still be considered a fringe case.

The tool does work amazingly well. That says a lot for the work that you folks put into it.

[SteveSims2]

Why not turn that tool off? Was the flag not working? As per TfsWorkItemEmbededLinkTool you can turn it off with:

{
  "MigrationTools": {
    "Version": "16.0",
    "CommonTools": {
      "TfsWorkItemEmbededLinkTool": {
        "Enabled": "False"
      }
    }
  }
}

I tried this. Somehow even when you turn that off, the dummy items get created anyway.