A lot of people want to know how long it will take to migrate their VSS database into TFS using VSSConverter.  There many factors that affect this, so it is impossible to give a truly accurate estimate.  However, I believe I have done enough migrations to give a ballpark that will be useful for most customers.  They are broken up into categories according to when you would be away from the keyboard. (so the migration doesn’t affect your productivity)

There is a closer correlation between the number of actions to migration time than there is the database file size, but I will give both because number of actions is hard to guess without actually running the converter.  By “action” I mean a change recorded in VSS such as ”Added”, “Checked in”, or ” Renamed”.

 

“Over Lunch”   0-2 Hours              

Database File Size (in Gigabytes):  0-2

Number of actions: 0- 20,000

 

“Over Night”   2-14 Hours

Database File Size (in Gigabytes): 2- 8

Number of actions: 20,000- 100,000

 

“Over the Weekend”  14-36 Hours

Database File Size (in Gigabytes): 5-10

Number of actions: 100,000- 700,000

 

Longer Migrations

The largest database I was able to get contained 1.6 million actions in 20 gigs and took roughly 20 days to migrate.  If you are in a situation like this where you are not able to stop using the VSS database for long enough to complete the migration you have two options, smaller migrations or incremental migration.

 

Smaller Migrations

 You can migrate smaller parts of the database at a time, by mapping a deeper path.  (IE “$/project1”rather than “$/”)  In this scenario you will run the VSSConverter once for each chunk of the database.  You must make sure that the paths are completely unique. 

The trade off is if items are moved from one part of the database to another they will be migrated as separate items in TFS. i.e. If “$/Project1/subproject” were moved to “$/Project2/subproject”  and you were to map “$/Project1/” in the first migration and “$/Project2/” in the second migration.  The item “subProject” would be two separate items in TFS. (Querying history on one would not show history from the other).

For more information on mapping paths please see http://msdn.microsoft.com/en-us/library/ms253161.aspx

Incremental Migrations

Or can you perform multiple Incremental migrations.  This is where you create a backup copy of your VSS database and start a migration from that, let that run to completion, while using your production copy.  Then start another migration from the production copy (while its idle) with the same mappings.   The migration will start migrating from the last change it checked into TFS, thus migrating changes made since the backup was taken.

The trade off is that there is a cost each time a migration is started.  The VSSConverter must query the VSS database and analyze all the changes, then use that information to determine the last change that it migrated before it can migrate the next change.  If you have a large database and cannot dedicate long periods of time to the migration, there will be little net progress. 

While we fixed all the bugs I was able to find in 2008 SP1, Incremental migration did have a higher incidence of problems than a straight forward migration.

For more information on Incremental Migration see http://msdn.microsoft.com/en-us/library/ms400695.aspx