On the VSS side, there are conversion tools available for migration. They can mainly support version history (there are caveats that are explained in readme and docs). I have migrated over 50 VSS projects using the VSS enforcement tool. Retrieving data from VSS can be a little tedious and not very fast, but it works. If you have direct access to disks (i.e., not through a network resource) to the VSS repository, the conversion can go much faster. You can find information about the scripts here .
There is a simlar page for CVS for forced conversion here , although I have no direct experience with this. These links are good places to start. You can also search the Perforce mailing lists in the Perforce knowledge base located here . I'm sure you can find conversion information in the mailing list archives.
Transfer your old projects first. You can make sure your process is running. When we moved the active code to Perforce, I took one weekend and basically refused access to the servers and transferred the code to Perforce. Honestly, it was a fairly easy migration, and when people returned on Monday, they were ready to go. You might consider preparing your employees for Perforce cheat lists after the start of the migration.
The biggest mistakes may actually prepare your people for Perforce. If I did this again, I would first redirect our smaller active projects and prepare fewer people to use Perforce right away. As it was, I had to train more than 120 people on the first day after the migration, and that was not much. In addition, make sure that you do not have another 100 people who hit your server for a new synchronization on day 1. We launched our server several times during the first few days. We used a 32-bit Windows server, which I would not recommend. Now we have a 64-bit server, and it is much more reliable. If you can, I would use Linux as the OS for your perforce server. Again, there should be good performance information on the Perforce site.