TestTrack Pro to TFS Migration

Description:

The client had a large number of defects that had been stored and tracked in Seapine's TestTrack Pro product over several years. Driven by a desire to consolidate their lifecycle management tools, the client needed to migrate these existing defects into Team Foundation Server.

Solution:

Using TestTrack Pro's export capabilities, the defects were first exported to an external XML file. Then, using a custom program that was written using the TFS SDK, the defects in the XML file were read in and subsequently written to TFS work items. Along the way, we were able to also migrate attached files (which were stored in separate files during the export process), and maintain link consistency between defects.

Maintaining link consistency was done by keeping a mapping of old defect numbers to new defect numbers, and then creating work item linkages in TFS that corresponded symantically to the original linked defects. For example, if TestTrack Pro had two linked defects, 1047 and 1098, and the old defect 1047 was now stored in TFS as 5443, and the old defect 1098 was now stored in TFS and 5587, then we created a link in TFS between work items 5443 to 5587 to mirror the orginal link symantics.

When defects are migrated from an old system to a new system, the defect fields need to be mapped from the old system to the new system. To accomplish this, there must be a way to describe these field mappings. Given that we were writing a custom program, we could have simply embedded these mappings as business logic within the program. This would have required recompiling the program between each iteration. To avoid this, we stored the field mapping logic in an XML configuration file. The client then only needed to change the configuration file if they needed to tweak their field mappings.

Project Lessons:

In theory, migrating defects from an old system to a new system should be relatively easy. In practice, it is trickier than it may appear at first blush. Here is a list of issues to keep in mind during any migration project.

	Process Design - To the extent possible, the design of your TFS processes, including fields and workflows, should be done before attempting a migration effort. It is difficult to properly map the old system's records into the new system, if the configuration of the new system is still in flux.
	Migration Planning - Planning is extremely important. The mapping of fields and processes should be done before attempting to migrate data.
	Testing - Testing is also important. One should not expect that the first import run will run flawlessly and map all fields as desired. It is an iterative process.
	Error Recovery - Error handling and recovery should be incorporated into the migration program. In other words, if the migration process fails part-way through due to an error, there must be a way to restart the migration process to complete the items that were skipped in the first pass. Duplicate item checking is important in this case.
	Artifact Migration - While there are some simple import facilities available with TFS's built-in capabilities, similar to other ALM solutions on the market, they don't allow you to fully migrate the work item artifacts, such as attached files and related work item linkages. A custom program will most likely need to be written to migrate this data. This is one reason why our clients have to chosen to utilize our consulting efforts rather than attempt a migration effort on their own using built-in tools.
	Version Control History - You should think carefully about how important it is to maintain your version control history from the old system to the new system. Some teams prefer to migrate this data, believing that the information will prove useful in reporting, comparing, and searching. Other teams feel like they would prefer a fresh start, and choose to migrate only the current version of each source file, but not the entire revision history. Migration of revision history is made more difficult by TFS's lack of support for timestamp control, thus it is not possible to exactly duplicate the old revision history within TFS. Revision history can still be migrated, but the revision dates will not be accurate.