I'm new to these forums, and had posted the following in the Visual Studio Team General forum. It looks like this is the better place for this question. Sorry for the cross post.

I'm looking for some strategy whitepapers or documents on how an existing development organization should go about planning a migration to Team System.

My development organization has a bug tracking system, we have a source control system, we have testing tools, and project management tools, and we maintain and enhance existing products built with VS2003, VS6 (C++ and VB6), and a bit of Java. We know we will be moving to VS2005 at some point, and we have new needs that our existing bug tracking and testing tools will not handle. So Team System looks compelling.

However, we clearly cannot just shut everything down and start over with Team System. We need to adopt pieces and parts of Team System incrementally without major disruption to the business.

Has anyone contemplated this, and is there any documentation around that would help us plan a reasonable strategy?

To be a bit more specific, we would probably want to start using Work Item Tracking in a standalone fashion to replace our bug tracking system (currently implemented in Lotus notes). How well would Work Item Tracking work without the other features of the TFS being used?

Clearly there are a lot more questions like this as we contemplate the migration, but I presume others have already started down this path, and was hoping for some advice/assistance from those who have gone before us.

Thanks, Alan.

Team foundation team recognizes the need for migration tool and towards that end we ship with two migration tools in the box

1. VSSConverter to migrate data from Visual Source Safe to Team Foundation Source Control.
2. CQConverter to migrate work items from ClearQuest to Team Foundation work item tracking.

There are lots of other work item tracking and source control systems for which we will not be shipping a migration tool. We are working on some documentation/samples that will help customers like you in writing their own migration tool. However such documentation will take some time and I cannot commit on a date at this time. In the meantime if you have some specific How To question about migration tool, you can send me a mail at amitagr at microsoft.com. The help documentation on CQConverter and VSSConverter available on MSDN would be a good starting point as you set out to write your own converter.

Team Foundation work item tracking is a fine work item tracking tool in its own right and you can use it in stand alone fashion to track your work items. Apart from the integration with other Team Foundation components like source control, you will get the full functionality. In our own dogfood of the product some teams used the work item tracking in stand alone fashion.

It is something we've put a lot of thought into.  We recognize the migration is going to be an incremental process for most people.  We've written some documentation (I'll forward this to the doc team so they can point you at some).  I think we've still got a ways to go and will continue to work on migration documentation, tips, utilities, etc for many months to come.  As Amit said, if you have any specific questions, feel free to post them here.

Brian

Hi Alan,

We have documentation around migrating from ClearQuest to Team Foundation work item tracking, and migrating from Visual SourceSafe to Team Foundation version control. For the complete table of contents of migration topics, see "Migrating to Team Foundation" on the http://msdn2.microsoft.com web site.

We are working on documentation around broader migration strategies and planning for Team Foundation Server. This documentation will be available in the future. To keep tabs on our latest documentation efforts and new topics posted to the web, see our Visual Studio Team System User Education blog.

Hope this helps,

David Chesnut MSFT
(This posting is provided "AS IS" with no warranties, and confers no rights.)

Hi David,

I'm working with a client who would like to import bug records from a legacy Lotus Notes database into TFS. We have the field mappings ready to go, and they aren't horrible. Is there any easy way to do this on the database side of TFS without requiring a migration tool of some kind?

Thanks,

Hi Seth,

Unfortunately there is no easy solution for what you are trying to do. I don't recommend trying to import bug records by interfacing directly with the Team Foundation Server work item database. You could inadvertently corrupt one or more of the TFS databases. TFS is designed so that client applications get and update data through the object model.

If the bug records are simple, you may be able to import them by copying them to a work item list in Excel, and then publishing them to the database. That's the simplest solution I can think of. Otherwise you will need to write your own converter using the SDK.

For the future, we are working on the development of a toolkit to address issues around migration similar to this one. There are no specific details at this time.

Hope this helps,

David Chesnut [MSFT]

Hi David,

Thank you for your response. Please understand that a better toolkit is critical for a company like ours. A big part of our training and mentoring approach includes evangelizing VSTS, but it's difficult to do that when you consider what some customers face when they consider how to migrate vast amounts of existing data--usually in the form of bugs.

Regards,