TFS Strategy for moving large number of projects from Source Safe

Question

The company I work for has over 1000 apps which we maintain. Many of these are in old technologies like VB6, or poor technologies (Access).

We are looking to move away from Source Safe. We have TFS running, and we are moving our dot.net projects to TFS. The other projects don't integrate with TFS, and do not need a portal or any of the other TFS features (except source control).

I'm concerned about leaving the other projects in Source Safe due to the unreliability of the product.

As far as I can see, there are two options:

1) Create a empty project in TFS called "VB6" (for example). Branch it for each VB6 app which is in VSS. This will put all the VB6 apps in that sub folder. This way, all apps can be in TFS.

2) Put dot net projects in TFS. Create a CVSNT repository and put all other VSS projects in there.

3) Put dot net projects in TFS. Leave all other projects in VSS. Run a weekly compact and repair on all VSS databases.

Which option do people feel is the best? Has anyone else been in a similar situation?

Answer 1

Git > TFS, use that instead.

Answer 2

Option 3 seems like the most economical bet in a situation like this, assuming that the VSS repositories stay <1-2GB in size (my understanding is that they're much more prone to corruption when they get larger-- this is going off memory, though, so I could be wrong). Keep a backup of the VSS in a physically separate location for insurance, and otherwise keep going as-is. There's relatively little ROI for making a move like you describe in the general case.

Answer 3

None of the three options make sense to me. If you are looking to move away from SourceSafe, and have already decided on moving to TFS (at least for your .NET projects), then it seems essentially what you are asking is if there is a good way to migrate the source for the 1000 older technology applications to TFS?

My recommendation is to simply use the Source Control Explorer as your SCC client for TFS. It works similar to the SourceSafe GUI. Any reason that wouldn't work?

Answer 4

The issue IMHO is your defintion of "Project". A Team Project is a high level container used to define processes and isolation. There is no reason not to have a VB6 Team Project with a complex Source Tree. There is no need to create actual "Branches" (in the Branch and Merge) sense for each VB6 app. Just the same folder structure you have in SCC.

So essentially I don't see any reason not to do your first option - just don't bother with the overhead of branching (unless you have an actual need for it)