HomeContactSitemapCompany Privacy PolicyLegal NoticeGeneral Terms and Conditions

Perforce Migration

The features and limits of the Perforce-to-TFS migration solution are described below.

Design differences between Perforce and TFS

The main differences between the two systems are the use of uppercase and lowercase letters in file paths (in the case of Unix-based Perforce systems) and the handling of directories which will be described below.


  1. Supports files as versioned elements of the version management.
  2. Directories are implicitly given by file paths and are not explicit elements of the version management.
  3. Directory operations (e.g. renaming) are treated as file operations of the contained files.


  1. Supports files as versioned elements of the version management.
  2. Supports directories as versioned elements of the version management.
  3. Directory operations are atomic operations and checked in directly.

Accepting the complete or partial history

To enable migration from a Perforce repository to TFS, the check-in processes from Perforce are reconstructed at the TFS side. This results in a new check-in time in TFS which deviates from the original one (see the Date column in the figure below). Therefore, the original time stamp of the check-in has been accepted in the comment in TFS together with the original check-in comment (see the Comment column in the figure below). The original user who carried out the check-in is also accepted during the migration. It is possible to configure a mapping to map the Perforce user accounts to the Windows users in TFS (see the User column in the figure below).

The type of operations and the branch relations are maintained as far as possible (there are restrictions on branching a file into several target branches within a Perforce change list). This is shown in the Change column in the figure above. The change lists are accepted 1:1 as a change set - transaction security is thus guaranteed. The following figure displays in detail the migrated change set 17 marked above.

The change list details clearly demonstrate that, in addition to the original comment, further metadata for migration, e.g. the IP or name of the migrated repository, are transmitted.

Deleted objects

Besides Add, Edit, Branch, and Merge, typical operations also include Delete. Our migration solution also migrates deleted (not purged) elements, as shown in the figure below.


Labels are also accepted. Labels in TFS are names for compiling various versions of a number of files and directories and can, among other things, be requested via the history of an element. The figure below shows the list of labels for a branch.

Accepting the branch relations

A main part of the migration is the branch relations of the source repository. These are essential for future integrations. Our migration solution accepts the branch relations from Perforce. In order to enable the visualization of the changes depicted below, only the root directories of the migrated branches in TFS must be turned into so-called branch folders after migration. This takes place once with three clicks in Visual Studio.

Restrictions during migration

Restrictions during migration generally affect file and directory names in Unix-based Perforce repositories which are not compatible with the Windows file system. These are special characters (e.g. $ characters are not allowed as the first character in file names) but also long paths (more than 260 characters).



Daniel RiƟmann
T: +49 (711) 490 664 31
Send an email