Best practice to migrate audit trail entries with migration-center

Colleague | Cosmin Anechite

Author
Cosmin Anechite
Migration Consultant @ fme SRL

May 3rd, 2021

Most document management systems (DMS) include so-called audit trails, a mechanism for keeping track of changes made to an object or a document by the respective author. These changes could be entries such as create, modify, check-in/out, and save. Within a migration it might be a requirement to “copy” the audit trail entries as well. Let’s see how easy it is to manage this challenge with migration-center!

One to one audit trail migrations

If the source and the target system are the same platform, the audit trails can be migrated one to one provided that this capability is supported by the according migration-center connector. Thus, an exact copy of each audit trail object and each entry can be achieved.

For migration-center’s OpenText Documentum (DCTM) connector, this is quite an easy task: to extract the audit trails besides documents and/or folders, you can check the “ExportAuditTrails” parameter in the scanner. For this purpose, the distinct migration set (migset) type is (DctmToDctm(auditrail)).

01 | Blogpost | Best practice to migrate audit trail entries with migration-center

Migration set type

Creating the mapping for a one to one copy is done virtually with a single click on the “Generate Rules” button in the migset. Automatically, a transformation rule will be created for each source entry which can then be auto-associated to the target audit trail attributes. The standard DCTM audit trail object definition has already been stored after installing migration-center – in case of a custom definition, it must be pre-configured through the client before starting the mapping procedure.

02 | Blogpost | Best practice to migrate audit trail entries with migration-center

Transformation rules

Partial audit trail migrations

Occasionally, it is not desirable to migrate each audit object or each entry from the source system. This occurs especially in case there are (too) many audit trail entries or, for instance, if objects or entries don’t necessarily have to be migrated because they won’t be relevant in the new system anymore. In such situations, it is possible to change the scanner configuration.

03 | Blogpost | Best practice to migrate audit trail entries with migration-center

Scanner configuration

As seen in the screenshot above, you may choose the audit trial type, exclude audit trail objects with a data query language (DQL) query, and ignore specific attributes. In addition, attributes can be removed and the values can be changed in the migsets through applying transformation rules.

What to do in case audit trails are not supported

Not all migration-center connectors and not all target systems support audit trails. In those cases, the audit trail can be extracted and imported in a different way. One solution to maintain the information consists in exporting the audit trail into a PDF file and importing it – besides the actual document – into the target system. This approach applies also very well within the context of archiving.

04 | Blogpost | Best practice to migrate audit trail entries with migration-center

Exporting audit trail information into a PDF file

In other scenarios, it is possible to customize a connector according to the individual requirements. Additionally, the audit trail object migration can be done by using scripts after all documents and folders have been migrated successfully with the help of migration-center.