That was the topic of our discussion today at VSLive! San Francisco. Unfortunately, in the short amount of time (75 minutes) we didn't get too deep into all of the tools and techniques, but I did get my point across: I feel that Team Foundation Server (TFS) can do it all, and you should strive to migrate your source/revision control system, requirements and defect tracking system, document managing system, automated build and deployment system, and even your custom process workflow over to TFS.

That said, there are certainly situations where existing systems must be used. I identified two categories of such legacy software:

• Politicalware - somebody important in the organization bought or built the system and you there are strong feelings about migrating away from it
• Guiltware - the organization spends oodles (that's a lot) of cash on said software, maintenance/support, training, etc. and they haven't seen their ROI (and they may never see it)

I don't know what to tell you about the above situations, except that running in parallel (not good) or integration (better) would be an option. That lead us to the discussion of building custom software to do one-way and two-way synchronization with said systems. We briefly walked through the TFS Migration and Synchronization Toolkit (found on CodePlex) and I demonstrated the TFS to TFS Migration Tool (also found on CodePlex) which uses the toolkit.

I see Team Foundation Server as yet another great "grassroots" platform. Just like .NET was for the developers, TFS is for the team. So, I say get it installed no matter what, even if just for source control, which is the no-brainer. Once it's in-house, then work on migrating the work items, automated builds, and other systems over sooner, rather than later, so you can enjoy the end-to-end traceability, product quality reports, and process quality reports.

If you'd like to have a look at my slide deck, you can find it here and my demo files here (you'll need to download the SDK and CodePlex toolkit and tool separately).