Share via

Migrate from Visual SourceSafe

  • Article

You can use the Team Foundation VSSConverter command-line tool to migrate projects, files, version history, labels, and user information from your Visual SourceSafe database to your server for Team Foundation version control. This tool is included with Visual Studio Team Foundation Server.

For more information about Visual SourceSafe, see the following page on the Microsoft Web site: Source Control for Visual Studio.

To migrate data from your Visual SourceSafe database

  1. **Understand key concepts.   **Before you migrate the data from your Visual SourceSafe database to your server for Team Foundation version control, you should understand some key concepts. Team Foundation and Visual SourceSafe have significant functional differences. As a result, VSSConverter must modify certain kinds of data as it is migrated.

    For more information, see How VSSConverter Converts Your Data later in this topic.

  2. **Make sure that you have the required permissions.   **To perform the procedures in this topic, you must have several types of permissions. For more information, see Required Permissions later in this topic.

  3. **Plan and prepare for the migration process.   **Before you start the migration process, you can avoid serious problems for yourself and your team by taking steps to plan and prepare. For more information, see Plan and Prepare for the Migration Process later in this topic.

  4. **Analyze your data.   **Before you migrate your data from Visual SourceSafe to Team Foundation version control, you must first use the Analyze feature of the Visual SourceSafe Converter to determine whether any issues in your data will affect the outcome of the migration. This process also generates a user mapping file that is required to migrate your data. For more information, see Analyze Your Data later in this topic.

  5. **Migrate your data.   **After you have run the Analyze feature, you are almost ready to migrate your data. To migrate your data, you must specify how user names are migrated, create a migration settings file, and then run the Migrate command. For more information, see Migrate Your Data later in this topic.

  6. **Verify migration, and resolve issues.   **After the Migrate feature has completed, you should perform the following steps:

    • Review the report that was generated by the Migrate feature.

    • Check the data on your server for Team Foundation version control to make sure that the data from your Visual SourceSafe database was migrated correctly.

    After you have taken these steps, you may have to troubleshoot problems. For more information, see Verify Migration and Resolve Issues later in this topic.

Required Permissions

To perform the procedures in this topic, you must have the following permissions:

  • In the Visual SourceSafe database that contains the data that you want to migrate, you must know the password of the Admin account.

  • On the migration machine (the machine where Visual Studio is installed), you must be a member of the Administrators group.

  • On the database that VSSConverter uses, you must have "create database" permission. For more information, see Provide a Database for VSSConverter to Use later in this topic.

  • On your application tier for Team Foundation, you must be a member of the Team Foundation Administrators security group. For more information, see Team Foundation Server Permissions.

Plan and Prepare for the Migration Process

Before you begin the migration process, you can avoid serious problems for yourself and your team by taking steps to plan and prepare.

Consider options to reduce the time required

The converter provides migration options that can minimize the time to migrate either by reducing the migration time or by enabling your teams to work in version control during the migration. Evaluate which of the following migration options will work best for your team:

  • Migrate selected projects: Instead of migrating your entire Visual SourceSafe database at the same time, you can migrate selected projects at different times. For more information, see <ProjectMap> Section later in this topic.

  • Truncate some of your historical data: You can use the archive feature of Visual SourceSafe to migrate partial history. Use this option if you are not interested in migrating old history. By using this feature, you remove the version history of files and folders before a specific date. For more information, see Truncate the History of Items later in this topic.

Schedule the migration with your team

Try to schedule the migration when users do not require access to the Visual SourceSafe database that you are migrating. You may want to allow for significant time to prepare and migrate your data if you have lots of data, a large team, or if you have worked on the projects for a long time.

Important

Inform your team members when the migration process will occur, and advise them to check in all files before the process begins.

Copy and prepare Your Visual SourceSafe database

Copy and prepare your Visual SourceSafe database by following these steps:

  1. Check in files.   Ideally, all files in your Visual SourceSafe database should be checked in. At least try to check in as many files as possible.

  2. Remove access to the Visual SourceSafe projects.   Make sure that you are the only person who has access to the Visual SourceSafe projects that you are migrating.

  3. Copy the database.   Follow the instructions that are provided on the following page of the Microsoft Web site: How To Back Up a Visual SourceSafe Database.

  4. Upgrade the copy of your database.    If your Visual SourceSafe database is a version earlier than Visual SourceSafe 6.0, upgrade it to Visual SourceSafe 2005 by using the Visual SourceSafe DDUPD utility. For more information, see the following topic on the Microsoft Web site: DDUPD Utility.

  5. (Optional) Truncate the history of items.   For more information, see Truncate the History of Items later in this topic.

  6. Scan for and fix data integrity issues in the copy of your database.   Use the Visual SourceSafe ANALYZE utility to locate and fix data integrity issues in the database. For more information about how to use this tool, see the following pages on the Microsoft Web site: ANALYZE Utility and How to Detect and Fix Database Corruption Errors in Visual SourceSafe.

Truncate the history of items

If you do not want to migrate all of the history that is stored in Visual SourceSafe, you can migrate only the history after a specific date by using the archive feature in Visual SourceSafe.

Warning

Use of this method permanently removes the version history from the Visual SourceSafe database. Therefore, make sure that you perform this procedure on a copy of the Visual SourceSafe database instead of the database that is in service.

To truncate the history of your items in Visual SourceSafe, use the archive functionality in Visual SourceSafe. You can specify the time stamp before which you want to truncate the history by using any of the following values:

  • Label

  • Version of a folder

  • Date

For more information about how to archive in Visual SourceSafe, see Visual SourceSafe Archive Databases.

Note

The Visual SourceSafe archive feature has a limitation of 2 gigabytes (GB) on the size of the archive file. If an error occurs during the process, try to archive smaller projects separately.

Prepare the migration machine

Prepare the migration machine by following these steps:

  1. Make sure that the machine has sufficient free disk space to complete the migration process. To estimate how much disk space is required, total the following items:

    • 5 GB of disk space that is available for VSSConverter to create temporary files and to generate log files.

    • Disk space that is equal to two times the size of the projects in the Visual SourceSafe database that you will migrate.

    • Disk space that is sufficient to install the applications that are described in the following steps.

  2. Install Visual Studio on the migration machine. 

    Important

    VSSConverter requires a database (either SQL Server Express or SQL Server) to function. By default, when you install Visual Studio, SQL Server Express is installed, and you are granted the permission that is required for VSSConverter to function. For more information, see Provide a Database for VSSConverter to Use later in this topic.

  3. Install Visual SourceSafe 2005 on the migration machine.

  4. Install the update that is associated with article 950185 in the Microsoft Knowledge Base. You can obtain this software from the following page on the Microsoft Web site: KB950185 - VSS Required QFE for Orcas SP1 VSSConverter.

  5. Make sure that you have followed the steps in Copy and Prepare Your Visual SourceSafe Database.

  6. Copy the Visual SourceSafe database to a folder on the migration machine.

    Warning

    If you use file sharing to enable the migration machine to access the data in the Visual SourceSafe database instead of copying the database, you must provide Read and Modify access to the account that you use to log on to the migration machine. This approach is not recommended because it may prolong the migration process.

    Important

    Regardless of how you set up your migration machine to access your Visual SourceSafe database, make sure that you run the migration process on a copy of the database and not the database that is in service. This approach helps protect your data.

Provide a database for VSSConverter to use

VSSConverter requires a database (either SQL Server Express or SQL Server) to function. By default, when you install Visual Studio, SQL Server Express is installed. If you decide to clear this option when you install Visual Studio, you must either manually install SQL Server Express later or use SQL Server as the database.

Whichever database you use, you must have the "create database" permission on the database. For SQL Server Express, this permission is granted to you automatically if you install it together with Visual Studio.

If you want to use SQL Server instead of SQL Server Express, you must modify the settings file. For more information, see <SQL> Element later in this topic.

Prepare your instance of Team Foundation Server

Prepare the migration machine by following these steps:

  1. Make sure that the data tier for Team Foundation has enough storage space available. You will probably need about two times the data size of the projects in the Visual SourceSafe database that you are migrating.

    This requirement may be higher or lower depending on the following factors:

    • The size of the Visual SourceSafe database under migration.

    • The number of actions to be migrated.

  2. The Migrate feature requires that the team project collections and team projects already exist on your server for Team Foundation version control before the migration process can start. If you do not yet have the team project collection or the team project into which you want to migrate your Visual SourceSafe data, perform one or both of the following steps:

    • Create a team project collection into which you want to migrate the data from your Visual SourceSafe database. For more information, see Create a Team Project Collection.

    • Create one or more team projects into which you want to migrate the data from your Visual SourceSafe database. For more information, see Create a Team Project.

Analyze Your Data

Before you migrate your data from Visual SourceSafe to Team Foundation version control, you should first use the Analyze feature of the Visual SourceSafe Converter to determine whether any issues in your data will affect the outcome of the migration. This feature also generates a user mapping file that the Migrate feature uses to migrate your data.

Create an analysis settings file

To use the Analyze feature, you must create a settings file. In this file, you specify the path of the Visual SourceSafe database that you will migrate and the folders that you want to migrate.

The following XML is an example of an analysis settings file.

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
<ConverterSpecificSetting>
     <Source name="VSS">
          <VSSDatabase name="c:\ourvss"></VSSDatabase>
          <UserMap name="c:\ourvss\migrate\Usermap.xml"></UserMap>
     </Source>
     <ProjectMap>
          <Project Source="$/Core"></Project>
          <Project Source="$/ProjectA"></Project>
          <Project Source="$/ProjectB"></Project>
     </ProjectMap>
</ConverterSpecificSetting>
<Settings>
     <Output file="c:\ourvss\migrate\logs\ContosoVSSAnalyze.xml"></Output>
</Settings>
</SourceControlConverter>

You can copy the previous example, paste it into your own settings file, and then modify it. The following information can help you adapt the example to meet your needs.

<?xml encoding> attribute

The <?xml encoding> attribute must match the encoding that is used in your settings file. For example, if the file is saved as Unicode, the <?xml encoding> tag is as follows:

<?xml version="1.0" encoding="unicode">

<VSSDatabase name> attribute

In the <VSSDatabase name> attribute, specify the path of the folder that contains the srcsafe.ini file for the copy of the Visual SourceSafe database that you are migrating. The following code is an example.

<Source name="VSS">
   ...
   <VSSDatabase name="c:\ourvss"></VSSDatabase>
   ...
</Source>

The path must not contain the string srcsafe.ini. For example, the following <VSSDatabase name> attribute is incorrect and will cause the VSSConverter command to fail:

<Source name="VSS">
   ...
   <VSSDatabase name="c:\ourvss\srcsafe.ini"></VSSDatabase>
   ...
</Source>

<UserMap name> attribute

The Analyze feature gathers and compiles data about your Visual SourceSafe users and stores it in an XML file. Optionally, you can specify the path and name of the file where you want this data stored in the <UserMap name> attribute. If you do not specify this attribute, the Analyze feature creates a file that is called UserMap.xml and puts it in the current directory.

<ProjectMap> section

In the <ProjectMap> section, specify the path of each Visual SourceSafe project that you want to migrate in the Source attribute of a <Project> item.

To migrate all the data in your Visual SourceSafe database, make the <ProjectMap> section match the following example:

<ProjectMap>
   <Project From="$/"></Project>
</ProjectMap>

Instead of migrating your complete Visual SourceSafe database at the same time, you can migrate selected projects at different times. This option can help you avoid blocking teams during migration if you have lots of data to migrate.

The paths in the Source attributes must not overlap. For example, the following <ProjectMap> section is not valid:

<ProjectMap>
   <Project Source="$/ProjectA"></Project>
   <Project Source="$/ProjectA/Controller"></Project>
</ProjectMap>

<Output file> attribute

In the <Settings> section, in the <Output file> attribute, you can specify the path and name of the file where you want the analysis report to be written. If you do not specify this attribute, the converter writes the report to a file that is named VSSAnalysisReport.xml and puts it in the current directory.

<SQL> element

To direct the converter to use SQL Server instead of SQL Server Express, you can add a <SQL> element to the <Source> section of your migration settings file. This element uses the following syntax: <SQL Server="SQL_Server_name"></SQL>.

For example, the following <SQL> element indicates that the server is "ContosoSQLServer":

<Source name="VSS">
   ...
   <SQL Server="ContosoSQLServer"></SQL>
   ...
</Source>

Run the Analyze command

To analyze a project by using the converter

  1. Click Start, point to All Programs, point to Microsoft Visual Studio 2010, point to Visual Studio Tools, right-click Visual Studio 10.0 Command Prompt, and then click Run as administrator.

    If the User Account Control dialog box appears, click Continue.

  2. Type the following command line:

    VSSConverter Analyze settings.xml

    Replace settings.xml with the path and name of the analysis settings file that you created.

  3. When you are prompted, provide the administrator password for Visual SourceSafe.

    VSSConverter displays the ongoing status as the Analyze feature proceeds. When the process is completed, the Analyze feature generates a report and a user mapping file.

Review and resolve issues found by the Analyze feature

The analysis report provides information about issues in your Visual SourceSafe database that may cause problems during the migration process. Try to resolve as many of these issues as possible to minimize problems with the migration process, as described in the next section.

Some Files are Checked Out

The report lists files that are currently checked out. The migration process does not preserve checkout information. Ideally, all files in your Visual SourceSafe database should be checked in. At least try to check in as many files as possible.

Some Items have Data Integrity Issues

The report lists items whose data integrity has been compromised. These items will not be migrated. The Visual SourceSafe ANALYZE utility may be able to fix these kinds of issues. For more information, see the following pages on the Microsoft Web site: ANALYZE Utility and How to Detect and Fix Database Corruption Errors in Visual SourceSafe.

Some Folders in Mapped Projects Contain History that is Not Included in the <ProjectMap> section

If a folder is moved from one project to another in a Visual SourceSafe database, the history of that folder is contained in both the original and current projects. To migrate such a folder with all of its history, you must migrate both the original and current projects.

For example, you are migrating the Visual SourceSafe project Project2. This project contains the folder $/Project2/FeatureA, which was moved from Project1 at some point in its history.

If your <ProjectMap> section contains…

For example…

Then…

Both projects.

 
<ProjectMap>
   <Project Source="$/Project1"></Project>
   <Project Source="$/Project2"></Project>
</ProjectMap>

The folder is migrated with its full history.

The project that originally contained the folder but not the project that currently contains it.

 
<ProjectMap>
   <Project Source="$/Project1"></Project>
</ProjectMap>

The folder is not migrated.

The project that currently contains the folder but not the project that originally contained it.

 
<ProjectMap>
   <Project Source="$/Project2"></Project>
</ProjectMap>

The folder is migrated with its history starting from when it was moved to the current project. The history that occurred before the folder was moved to the current project is not migrated.

For more information about the <ProjectMap> section of the settings file, see <ProjectMap> Section earlier in this topic.

Some label names are not supported by Team Foundation version control

The report lists label names that will change when they are migrated because they contain characters that Team Foundation version control does not support.

Migrate Your Data

After you have run the Analyze feature, you are almost ready to migrate your data. Before you run the Migrate command, you must create a migration settings file. Optionally, you can specify how user names are migrated.

Specify How User Names are Migrated

You can control how user information is migrated from Visual SourceSafe to Team Foundation version control. Specifically, you can specify what user name the Migrate feature should associate with each changeset in the history of each item in Team Foundation version control. You do this by editing the user mapping file that was created when you ran the Analyze feature, as explained earlier in this topic.

The user mapping file is optional. If you omit the <UserMap> element from your settings file, each changeset is built in the following manner:

  • The User field is set to the name of the account under which VSSConverter is running.

  • The name of the user who performed the action in your Visual SourceSafe database is stored in the Comment field.

Example of a user mapping file

When you run the Analyze feature, it compiles data about your Visual SourceSafe users and stores it in an XML file. This file lists every Visual SourceSafe user who has ever performed a version control operation in the Visual SourceSafe projects that you are migrating.

The following example shows a user mapping file that was created by the Visual SourceSafe Converter Analyze feature.

<?xml version="1.0" encoding="utf-8"?>
<UserMappings>
   <UserMap From="Admin" To=""></UserMap>
   <UserMap From="Guest" To=""></UserMap> 
   <UserMap From="Kim" To=""></UserMap>
   <UserMap From="Satomi" To=""></UserMap>
   <UserMap From="Mark" To=""></UserMap>
</UserMappings>

You can specify the To attribute of none, some, or all of the UserMap items in the user mapping file. For example, you could modify the previous example in the following manner:

<?xml version="1.0" encoding="utf-8"?>
<UserMappings>
   <UserMap From="Admin" To="NORTHAMERICA\KenM"></UserMap>
   <UserMap From="Guest" To="Test1"></UserMap> 
   <UserMap From="Kim" To="EUROPE\KimT"></UserMap>
   <UserMap From="Satomi" To="ASIA\SatomiH"></UserMap>
   <UserMap From="Mark" To=""></UserMap>
</UserMappings>

Notice that in the previous example, Guest is mapped to Test1, and no domain is specified. In these cases, VSSConverter presumes that the account belongs to the default domain.

If you do not specify a <UserMap To> attribute, each changeset is built in the following manner:

  • The User field is set to the name of the account under which VSSConverter ran.

  • The name of the user who performed the action in your Visual SourceSafe database is stored in the Comment field.

  • If you specify a <UserMap To> attribute and the value is a valid user on a server that is running Team Foundation, the User field is set to the name of that account. If the value is not a valid user on a server that is running Team Foundation, VSSConverter will display an error and end the migration process.

Create a migration settings file

You use the migration settings file to specify what Visual SourceSafe data you want to migrate and to control several aspects of how you want to migrate it. The easiest way to create this file is to copy the file that you created in Create an analysis settings file earlier in this topic. You then add more data to the file to make it usable by the Migrate feature.

The following example shows a migration settings file.

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
<ConverterSpecificSetting>
     <Source name="VSS">
          <VSSDatabase name="c:\ourvss"></VSSDatabase>
          <UserMap name="c:\ourvss\migrate\Usermap.xml"></UserMap>
     </Source>
     <ProjectMap>
          <Project Source="$/Core" Destination="$/CoreTeamProject"></Project>
          <Project Source="$/ProjectA" Destination="$/ClientTeamProject/ProjectA"></Project>
          <Project Source="$/ProjectB" Destination="$/ClientTeamProject/ProjectB"></Project>
     </ProjectMap>
</ConverterSpecificSetting>
<Settings>
     <TeamFoundationServer name="My_Server" port="8080" protocol="http" collection="tfs/DefaultCollection"></TeamFoundationServer>
     <Output file="c:\ourvss\migrate\logs\ContosoVSSMigrate.xml"></Output>
</Settings>
</SourceControlConverter>

The following information can help you modify the settings file to specify how the Migrate feature will migrate your data.

<Project Destination> attribute

For each <Project> element in the <ProjectMap> section of your settings file, provide a Destination attribute to specify the path of the location on your server for Team Foundation version control where you want to migrate the contents of the project in your Visual SourceSafe database (specified in the Source attribute).

For example, you want to migrate the contents of ProjectA in your Visual SourceSafe database into ProjectA at the root of a team project that is called Client.

<ProjectMap>
   <Project Source="$/ProjectA" Destination="$/ClientTeamProject/ProjectA"></Project>
</ProjectMap>

For the value in the Destination attribute to be valid, the following conditions must be true:

  • The team project in the Destination attribute (in the previous example, the team project is ClientTeamProject) must already be located in the team project collection before you start the migration process.

  • If the folder in the Destination attribute (in the previous example, the folder is ProjectA) is already located in the team project, the folder must be empty.

  • The path in the Destination attribute of a <Project> element must not overlap the path in the Destination attribute of any other <Project> elements. For example, the following <ProjectMap> section is not valid:

    <ProjectMap>
   <Project Source="$/ProjectA" Destination="$/ClientTeamProjectA/"></Project>
   <Project Source="$/ProjectB" Destination="$/ClientTeamProjectA/ProjectB"></Project>
</ProjectMap>

<TeamFoundationServer> tag

In the <Settings> section, add a <TeamFoundationServer> tag, and specify the name, port, protocol, and path of the team project collection on the server that is running Team Foundation Server by using the following format:

<TeamFoundationServer name="ServerName" port="PortNumber" protocol="http" collection="path/collection name></TeamFoundationServer>

<Label migrate="false" /> tag

If your Visual SourceSafe database contains many labels that are applied to many files, the migration process may be prolonged. If your team does not need this data, you can configure VSSConverter to ignore labels by adding the <Label migrate="false" /> tag to the <Settings> section.

<Output file> attribute

In the <Settings> section, in the <Output file> attribute, you can specify the path and file where you want the migration report written. If you do not include the attribute, the converter writes the report to a file that is named VSSMigrationReport.xml and puts it in the current directory.

Run the Migrate command

To run the Migrate command

  1. Click Start, point to All Programs, point to Microsoft Visual Studio 2010, point to Visual Studio Tools, right-click Visual Studio 10.0 Command Prompt, and then click Run as administrator.

    If the User Account Control dialog box appears, click Continue.

  2. At the command prompt, type the following command line:

    VSSConverter Migrate settings.xml

    Replace settings.xml with the path and name of the migration settings file that you created.

    The Migrate feature displays each project that you are migrating from your Visual SourceSafe database and each folder into which the data will be migrated on your server for Team Foundation version control.

  3. When you are prompted, press Y to confirm the migration.

  4. When you are prompted, type the password of the user who administers your Visual SourceSafe database.

During the process, the Migrate feature displays its current status in the Command Prompt window.

Resume the process by using incremental migration

If the migration process is interrupted for some reason, you can resume the process as an incremental migration from the point at which the process ended. An incremental migration can be useful if the migration process failed because of an error or network problems. During incremental migration, the converter will migrate only the data that was not migrated in previous sessions.

To start an incremental migration, follow the steps in Run the Migrate command. When the Migrate feature asks whether you want to perform an incremental migration, press Y.

Limitations of an incremental migration

An incremental migration will not succeed unless you comply with the following restrictions:

  • In your Visual SourceSafe database, you must not perform destroy, purge, archive, or restore activities.

  • You must not change the <ProjectMap> section of your migration settings file.

  • On your server for Team Foundation version control, you must not modify any folders (or any content in the folders) that are specified in the <ProjectMap> section of your migration settings file.

Verify Migration and Resolve Issues

After the Migrate feature has completed, you should perform the following steps:

  • Review the report that was generated by the Migrate feature.

  • Check the data on your server for Team Foundation version control to make sure that the data was migrated correctly.

After you have taken these steps, you may have to troubleshoot problems.

How to resolve exceeding the storage limit for SQL Server Express

By default, VSSConverter uses SQL Server Express to store temporary metadata. This metadata typically requires a small percentage of the total size of the data that you migrate. In the unlikely event that your migration fails because the 4-GB limit of SQL Server Express is reached, you can apply a setting that directs the converter to use a SQL Server deployment instead. For more information, see <SQL> Element earlier in this topic.

Convert files in the MS-DOS-Compatible short name (8.3) format (TF227014)

Team Foundation version control does not allow file names that are in the MS-DOS-compatible short name (8.3) format (for example, abcdef~1.txt). When you analyze or attempt to migrate files that have such a name, a TF227014 error appears.

To work around this issue, you can temporarily apply a setting to your application tier for Team Foundation that will cause it to allow files that have such names. To do this, you must set Allow8Dot3Paths to True in the configuration database for Team Foundation .

Important

To avoid issues with client machines that support MS-DOS-compatible short names, after you complete the migration process, it is strongly recommended that you set Allow8Dot3Paths to False as described in the following procedure.

To perform the following procedure, Windows PowerShell must be enabled on the application-tier server for Team Foundation. For more information, see the following topic on the Microsoft Web site: Scripting with Windows PowerShell.

Required Permissions

To perform this procedure, you must be a member of the Administrators group on the application-tier server for Team Foundation. For more information, see Team Foundation Server Permissions.

To migrate a Visual SourceSafe database that contains files that are named in the MS-DOS-compatible short name format

  1. Log on to the application-tier server for Team Foundation.

  2. Create a Windows PowerShell script that is called Allow8Dot3Paths.

    1. Copy the text in Allow8Dot3Paths PowerShell Script later in this topic, and paste the text into the script.

    2. Change ServerPath to match the path in the URL that you use to connect to Team Foundation Server. By default, the server path is "tfs".

    3. Change CollectionName to match the name of the team project collection into which you are migrating your data (for example, DefaultCollection).

      The end result, for example, would be the following line in the script:

      $collectionBaseUrl = "https://localhost:8080/tfs/DefaultCollection/";

  3. Run the Allow8Dot3Paths script.

  4. Recycle the application pool for Team Foundation.

    1. Click Start, click Administrative Tools, and then click Computer Management.

    2. In the navigation pane, expand Services and Applications.

    3. Click Internet Information Services (IIS) Manager, expand the local computer, and double-click Application Pools.

    4. Right-click the application pool, and then click Recycle.

  5. Run the Migration command.

    For more information, see Run the Migrate Command.

  6. Modify the Allow8Dot3Paths Windows PowerShell script that you created earlier, replacing "true" with "false".

  7. Run the modified Allow8Dot3Paths script.

  8. Recycle the application pool for Team Foundation.

    1. Click Start, click Administrative Tools, and then click Computer Management.

    2. In the navigation pane, expand Services and Applications.

    3. Click Internet Information Services (IIS) Manager, expand the local computer, and double-click Application Pools.

    4. Right-click the application pool, and then click Recycle.

  9. Open Team Explorer, and connect to the team project collection into which you migrated the data.

  10. In Source Control Explorer, rename any files that have names in the MS-DOS-compatible short name (8.3) format.

Allow8Dot3Paths PowerShell Script

# Load client OM assembly.
[Reflection.Assembly]::Load("Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");

$collectionBaseUrl = "https://localhost:8080/ServerPath/CollectionName/";

$tfs = [Microsoft.TeamFoundation.Client.TeamFoundationServerFactory]::GetServer($collectionBaseUrl);
$collectionHive = $tfs.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationRegistry]);

# Set some version control settings in the collection hive.
$collectionHive.SetValue("/Service/VersionControl/Settings/Allow8Dot3Paths", "True");

# Display all version control settings as a table.
$collectionHive.ReadEntries("/Service/VersionControl/Settings/...") | ft -a

How VSSConverter Converts Your Data

Team Foundation and Visual SourceSafe have significant functional differences. As a result, VSSConverter must modify certain kinds of data as it is migrated.

Changesets

A key feature of Team Foundation version control is how it groups changes to multiple files into a single unit when a user checks in a set of changes. This single unit is known as a changeset.

Visual SourceSafe does not have a feature that is equivalent to changesets. However, during the conversion process, each set of changes is grouped into a changeset as long as the following conditions are true:

  • The changes do not conflict with each other. For example, no two actions affect the same file or folder.

  • The changes occurred within no more than a few minutes of each other.

  • The changes were checked in by the same user.

  • The changes have the same check-in comment.

For more information, see Working with Changesets.

Sharing and Pinning

In Visual SourceSafe, you can share a file across multiple folders. Changes that you make in a shared file are replicated across the folders in which the file is shared. Team Foundation version control does not have an equivalent feature. During migration, shared files in your Visual SourceSafe project are migrated by creating an additional independent copy of the item on your server for Team Foundation version control.

Team Foundation version control does not have a feature that is equivalent to the Pin feature in Visual SourceSafe. During migration, pinned items in the Visual SourceSafe project are converted to labeled items on your server for Team Foundation version control. For more information, see the next section.

For more information about labels in Team Foundation version control, see Use Labels to Take a Snapshot of Your Files.

History data

Each event in the history of an item in your Visual SourceSafe database is transferred onto your server for Team Foundation version control as a changeset. After the migration process is completed, you can view this data in the History window. For more information, see Using the History Window.

Some changes to the data occur during migration.

How data about the user name and the date and time stamp is migrated

As each entry in the history of an item in your Visual SourceSafe database is migrated to a changeset on your server for Team Foundation version control, the following changes occur:

  • The date and time stamp on the changeset is set to the date and time when the item was migrated.

  • The original date and time stamp is stored in the Comment field of the changeset.

  • The user name is stored in either the User field or the Comment field of the changeset, depending on the result of the user mapping process. For more information, see Specify How User Names are Migrated earlier in this topic.

How Specific Types of Events are Converted

Events such as edit, rename, and delete are migrated from your Visual SourceSafe database into changesets on your server for Team Foundation version control in a straightforward manner. However, VSSConverter migrates some events in ways that you might not expect, as the following table shows.

Visual SourceSafe Event

How it is migrated into Team Foundation

Add file or folder

This changeset is the first event in the history of each file and folder that is migrated.

Unlike in Visual SourceSafe, no event is logged for the parent of each child item that it contains.

Branching

Sharing is a precondition of branching in Visual SourceSafe, but Team Foundation version control does not support sharing. Therefore, the migration of a branched file creates a copy of the file in the destination folder. 

The shared files in your Visual SourceSafe database are migrated to Team Foundation version control by copying the version of the file that existed when it was shared and putting the copy in the destination folder. Thereafter, each changeset is replicated in both copies of the file until the branch event occurs.

Label file 

In Team Foundation, you apply a label to a version of a file or folder. In Visual SourceSafe, you can label a file either explicitly or implicitly. When a file is explicitly labeled in Visual SourceSafe, a new version of the file is created. If you get files by using that label, you get the content of the file that corresponds to the version of the file that existed when the label was created. To migrate explicit labels, the converter takes the label that corresponds to the labeled version in Visual SourceSafe and applies it to the version in Team Foundation. However, it does not create a new version.

When you apply a label to a folder in Visual SourceSafe, the label is applied implicitly to all files and folders under that folder, and the converter does not create new versions. For implicit labels, the converter does nothing because the corresponding versions in Team Foundation are automatically labeled during migration of explicit labels on the folder.

NoteNote
If your Visual SourceSafe database contains many labels that are applied to many files, the migration process may be prolonged. If your team does not need this data, you can configure VSSConverter to ignore labels. For more information, see <Label migrate="false" /> earlier in this topic.

Label folder

In Visual SourceSafe, when you apply a label to a folder, all files and folders under that folder are implicitly labeled, and new versions are not created. During migration of these folders, the converter applies the label to the corresponding version of the folder in Team Foundation. This behavior automatically applies the label to the current versions of files and folders inside the labeled folder.

NoteNote
If your Visual SourceSafe database contains many labels that are applied to many files, the migration process may be prolonged. If your team does not need this data, you can configure VSSConverter to ignore labels. For more information, see <Label migrate="false" />.

Move folder

The Move Folder event creates a new version of the folder in Team Foundation.

VSSConverter will not migrate the complete history of items in moved folders unless both the source and destination folders are migrated at the same time. For more information, see Review and Resolve Issues Found by the Analyze Feature.

NoteNote
If the move folder event is combined with a restore event, the history data may not be migrated correctly.

Restore

No history data that occurs before a restore event is migrated.

PIN and UNPIN

Team Foundation version control does not support pinning. VSSConverter migrates a pinned file by creating two labels.

The PINNED_LATEST label is applied to the pinned versions of the pinned files and to the most recent version of the unpinned files. The PINNED label is applied to only the pinned versions of the pinned files. After migration, the PINNED_LATEST label will retrieve the same files as a Get Latest in Visual SourceSafe. However, the PINNED_LATEST label might return different files, if events other than checking in occurred after a file was pinned, such as renaming or deleting the file.

Sharing

Team Foundation version control does not support sharing. Shared files in your Visual SourceSafe database are migrated to Team Foundation version control by copying the version of the file that existed when it was shared and putting the copy in the destination folder. Thereafter, each changeset is replicated in both copies of the file.

Undelete File or Folder

During migration of undelete events of a file or folder, the converter replays the event to create a new version of the file and folder in Team Foundation.

VSSConverter creates a changeset that includes the file or folder name, the date and time when it was undeleted, and the user name.

Source Control Bindings

VSSConverter restores version control bindings for each solution.