Migrating Documents with Versions from File System to ECMs
There are several reasons to migrate documents with version information from the file system to an ECM system:
• Versioned documents on a file share often hold the version information within the filename.
• The file system is used as an in-between step during a migration from a proprietary system. As an example, when documents are exported to the file system together with XML metadata files.
This blogpost describes how to migrate documents to OpenText Documentum while maintaining version information. Migrations to other systems such as Microsoft SharePoint, Alfresco or OpenText Content Server work in a similar fashion.
Gathering the version information with the file system scanner
The file system scanner can generate versioning information from attribute values provided through an additional metadata file. One XML file should be available for each document. Technically it could also be one big XML file, but usually it is not recommended, depending on the number of documents that need to be scanned. The XML metadata file must contain the version number (“VVersion” in extract 1,2 & 3) and a unique identifier (“VStamm” in extract 1,2 & 3) for each document. These attributes can have completely different names in accordance with the companies requirements.
Configuring the scanner
When setting up the file system scanner, the following attributes are necessary. In the following you will find an example:
*Note: It is important to add the prefix “xml_” to the attribute name for “VersionsIdentifierAttribute” and the “VersionLevelAttribute”.
The migration set configuration
In the MigSet an association between “r_version_label” from OpenText Documentum and “xml_VVersion” must be established.
If the version identifier value is different than “1 or 1.x” – for example separated by comma -, the values can still be transformed using the default rules in the MigSet. The following rule is an example to replace commas by dots. In case you have data without a dot or comma, simply add a dot and a zero behind the version number.
Setting up the importer
The version information is now built and stored inside the migration-center database, as usual in a “neutralized” manner so every importer, which supports versions, can be used to import the documents.
For the OpenText Documentum importer no special configurations are required concerning the versioning. For other systems like MS SharePoint you should spend more thoughts on major/minor versions and restrictions such as the maximum allowed number of versions. The fact that no version numbers can be skipped is also important with MS SharePoint.
A migration of documents with versioning information from the file system is an out-of-the-box feature of migration-center. The scanner configuration is probably the most crucial part, but with the information from this blogpost, you should be able to set up a test scenario within a couple of hours.