TFS Bug/Feature Migration - Test Director to TFS (or how I learned to love the TFS Excel Add-in)

This weekend was bug/feature migration time. I have about 100 open items that I wanted to copy from our Test Director/Defect Manager (TD/DM) database to TFS.

After a quick search I didn’t see anyone having a canned solution. Which makes sense... Due to the customization options it would be a good bit of work to deliver a solution that would work for many/most users. Also this would be a limited volume product. Actually for the next few years, there’s going to be some good consulting dollars made from converting existing bug/feature/test databases into TFS.

So no canned solution from MS, Mercury or a third party. Next, write my own...

So I try to dig into the DB. Nope, I’m not allowed to access it directly. Dogh. Next, use the Test Director API?

Can’t find any info or data on the Test Director API (for our 7.6 version)...

Okay, low tech time. TFS Team Explorer installs a cool Excel Add-in. Via the new Team menu you can add existing Work Item lists to a spreadsheet OR use Excel to add new Work Items. TD/DM easily lets me save all my items as a XLS (minus attachments).

So I took my TD/DM XLS, created a new sheet and added a new TFS List, using the "Input List" option.

Via the Excel Team menu, I modified the listed columns to match those, as best I could, from my TD/DM XLS. Cut from TD/DM & paste into TFS XLS.

Then it was "resolve all the data validation issues" time. Map our lookup values to TFS’s. Add new TFS Area’s, etc, etc. The TFS Team add-in did a good job of validating the field/column values, making it clear which cells had issues. Excel’s Search and Replace became my friend in this step...

In a little more than an hour from start to finish (including the re-starts, do-over’s, etc) I was able to add all 100+ Work Items from TD/DM. And now that I know the tricks, then next time it will be MUCH faster.

One problem is that attachments must be manually copied over. That kind of bytes, but I only have a few defects (10 or less) with attachments, so that’s acceptable.

I did run into an "oh crud" issue. For my first pass, I added everything as a Bug Work Item. This was to just see if it would work... Now I wanted to do it all over again, but with a few more refinements, such as creating different Work Item types based on values stored in the TD/DM XLS (either Bur or Change Request). Easy enough, just delete those Work Items I already added and do it again, right?

There’s no supported way to delete Work Items (googled).

I chalk this up to another v1, let’s finally ship this thing, item. And in a normal world you wouldn’t want too many people being able to delete work items. Think about the dependency, referential integrity, etc, issues. Work Items can be (and should be) tied to code, other work items, etc. So how do you delete them without jacking up everything? You delete
them carefully... In vNext...

So tip of the day? Don’t test migrate work items into a production TFS Project.

Luckily I plan on reinstalling TFS anyway...

I think I’m pretty much done now with our test TFS run. I’m now playing with it and thinking about how to introduce using it in the real world to my co-workers...

Related Past Post XRef:
TFS VSS Mirgation and Team Build Config
TFS - Work Item’s and Customization
TFS Lesson #2 - Listen to my own advice...
TFS SQL Databases Moved... One Tip, Remember the DB Owner
"Moving Your Team Foundation Server Deployment"
My First Soup to Nuts Team Foundation Server Install
TFS Check In Policies, Code to Police Code
"An updated TFS MSSCCI provider is available"
VS6 MSSCCI Provider for TFS
TFS Administration Tool
"Migrating from Visual Source Safe to TFS"
"How many users will your Team Foundation Server support?"
Team Foundation Server 2005 & the "New" MSDN Universal

Technorati Tags: Team Foundation Server, TFS, Visual Studio Team Suite