Visual Source Safe --> TFS Migration

Question

Around here we have been working with a bunch of Visual Source Safe repositories for about 10 years or so.

Now I want to get rid of sourcesafe and move on to Team Foundation Server.

Do you have any tips or tricks for me before I embark on this migration? What are the things I have to be careful about?

I am sure this migration will mean that our working habits have to be modified in some way. Do you think that these changes could be a problem for the organization? Think about a group of about 20 .NET developers in a single site.

Answer 1

I just googled, but this walkthrough seems like a good reference, and it mentions the tool VSSConverter which should help you make the migration as painless as possible.

I would like to recommend one thing though: Backup. Backup everything before you do this. Should anything go wrong it's better to be safe than sorry.

My links aren't showing up. This is the address: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx

Answer 2

There are a few different ways you can migrate. The tool will pull your history, etc. over, but the more pragmatic and simple way is to lock VSS as a history archive and start fresh:

1. Have everyone check in all changes into VSS, make sure everything builds, etc.
2. Set all VSS databases to "locked" (read-only rights for all users)
3. Get Latest on the entire VSS database into a "clean" set of folders on a workstation
4. Check all of the files into TFS from the workstation

For any history prior to the conversion, folks need to go to VSS, but after a week or two it's realistically unlikely to happen all that often. And you know that the history in VSS is accurate and not corrupted by the conversion process.

Answer 3

Be aware that TFS does not support sharing files between different projects, as VSS does. If you have any such shared files the link between them will be broken during the migration, resulting in initially identical, but now distinct files in each project. Updates to one of these files in TFS will no longer propagate to the copies in the other projects.

Answer 4

We are currently in the process of doing this at my day job. We are actually making the switch over in about a month. I am a main part of the migration and a big part of why we are getting off of SourceSafe. To help in the migration, I used the Visual Studio® Team System 2008 Team Foundation Server and Team Suite VPC Image. It was very useful. Right off the bat, the image contains a full working TFS installation for you to play and demo with. It also includes Hands on Labs and one of the labs is running the VSS -> TFS migration tool. If you have an MSDN subscription, once you have played with the image, the next step would be to install the TFS Small Team edition that comes with your subscription.

One thing to note is to make sure you get the latest Service Packs for Visual Studio 2008 and the .NET Framework installed on the image. The service packs fixed some annoying bugs and it definately increased the usability of the system. We have a farely large SourceSafe database with about 90+ projects and the migration tool took about 32 hours to complete. First I made a backup of our sourcesafe database for testing. Then I made the migration on the test sourcesafe database. Afterwards, I checked the source tree in TFS and everything transferred fine. We kept all the history for our source files from VSS which was great. No need to keep that stinking VSS database around after we go live.

We are taking the migration in steps. First the source control and letting our developers get use to using it. Then after that we will be migrating the QA and Business Analysts over to use the Work Item tracking features.

My advice is to take the migration in steps. Don't do too much at one time. Give time for people who will be using the system to train up.

Answer 5

Good guidance there from my former colleage Guy Starbuck. Another thing to add with that approach - you may have decided over time that you want to refactor the way your application is organized (folders etc) and this will give you an oppurtunity to do so.

I've been in situations where we organized a solution haphazardly without thought (let alone major changes in the application) which led to a desire to organize things differently - and the move from VSS to TFS is a great oppurtunity to do so.

As far as the original question:

And: this migration will for sure mean that our working habits have to be modified in some way. Do you think that this changes could be a problem for the organization? Think to a group of about 20 .net developers, in a single site

I would say - yes your working habits will change but much more for the better.

1. You no should use "Check-out" Locks and "Get-Latest on Check-out".
2. You can now effectively Branch and Merge
3. You will now have "Changesets" all files checked-in at the same time will be grouped together. This makes historical change tracking much easier - but more importantly - rollbacks are much easier (ie find all files checked in at the same time and roll them back)
4. Associating Check-ins to Work Items. Don't overlook Work Items! The biggest mistake you can make is to only use TFS as a VSS replacement. The Build and Project Management features are excellent - you paid for them - USE THEM!

As far as details on how your experience will change, another former colleague of mine (and Team System MVP) Steve St. Jean wrote a detailed article on the differences: From VSS to TFS

Answer 6

If you do choose to use the VSSConverter.exe tool that ships with Visual Studio Team Foundation Server, then you should install TFS 2008 SP1 first as it includes a number of improvements as detailed on this blog by the migration tools team.

Some of the key features of the release include:

Elimination of namespace conflicts. I previously blogged about this as "the rename problem" and we have fixed the converter to correctly migrate files with overlapping namespaces. This was the biggest pain point for most users trying to use previous versions of the tool.

Automatic solution rebinding. In this latest version, VS solution files will be automatically upgraded to the 9.0 version and checked back in to version control. Previously users were required to do this manually.

Correcting of timestamp inconsistencies. The use of client timestamps by VSS can lead to revisions being recorded in the opposite order that they actually occurred in. The tool now recognizes this issue and continues migrating changes where it would previously fail.

Improved logging. Although we've fixed a lot of issues, providing better, more detailed logging will help users that do run into issues diagnose the problems.

Answer 7

VSS Converter is a far from perfect solution. And there are significant differences between the 2005 and the 2008SP1 version of the converter.

For example, in a VSS DB that's been in use for a long time, there will have been a large number of users contributing to VSS. Many of these users will have left the organisation a long time ago and therefore will no longer have domain accounts. TFS requires mapping VSS users to domain accounts, so you will have to decide whether you map old users to a single 'dummy' domain account or to a current team member.

In addition, VSS Converter 2008 requires these domain accounts to be valid TFS accounts. Whereas the 2005 converter does not enforce this.

If your VSS history contains significant folder Moves, then it's likely you will loose all history before this Move. For example, if you Move a folder to a new location, then Delete the previous parent, you will loose all history. See this article for more explanation: http://msdn.microsoft.com/en-us/library/ms253166.aspx

In one migration I was involved with, we had a 10 year old VSS database that lost all history prior to 6 months ago. This was due to a significant tidy up that took place 6 months ago.