Document management is no longer greenfield terrain. By now many companies have already determined their need for a document management system and understand the benefits it offers them, especially in the Life Sciences. For this reason, nearly every company dealing with mission-critical documents has implemented some sort of solution in recent years.
The question that is now more likely to arise is whether the performance level and user friendliness of today’s system are still adequate, and/or capable of meeting growing requirements. And it could be that other providers have developed a newer, more attractive solution.
How do you switch from an existing system with all of the data and documents that have built up over the years and that uses a specific data structure to a new system?
That new system that you’re eyeballing will definitely feature different structures for managing its databases and data. It is virtually impossible that two teams of developers will have developed compatible data structures for the same situation/problem. So, it means that a company wanting to switch to a new system has to migrate its legacy system to the new environment. The IT department will generally know the in’s and out’s of the legacy system pretty well, and with a little luck the provider or a third-party company will also help them transition to using the new application. No matter what, it’s still a major challenge to move the entire contents of your database to a similar structure in a new system.
How do you preserve the document history in a new application, as it is especially important for auditing?
Life Science companies often use a strict versioning status chain when storing documents (such as draft, review, approved, superseded, retired). Documentation that has either the ‘approved’ or ‘superseded’ status is nearly always connected logically, making it possible – in particular for an external audit – to track the chronological sequence of the versions. The process of replicating a document history in the new application as if you had processed the document there in the first place is very difficult and error-prone. Every minute detail of the database, in the stored data attributes can be of great importance. If an error occurs during migration, it can mean that the currently approved version cannot correctly be replaced by a later version and that the IT staff is forced to repair the transferred legacy data again and again after migration.
You need to keep in mind that when a document passes from one status to the next in a sophisticated document management system, it also triggers a series of actions: They will, for example, set new access permissions, calculate derived attribute values, or even request renditions in certain formats. Actually you would need to simulate all of these actions when implementing a low-level migration approach.
Hopefully, the new application also has a (documented!) API (Application Programming Interface), such as using Web services, class libraries, or suchlike. The prospects of being successful are far more promising if you can transfer documents and metadata into the new system using this API. For example, it is the reason why fme’s migration-center offers additional importers, in addition to a basic importer into a Documentum repository, that are interwoven at the application level, such as for FirstDoc or EMC D2.
How do you proceed with migration to a new application?
Normally, if the migration process takes place at the level of the API of an application, the legacy metadata from the documents is extracted. Then the data values are appropriately transformed for the new data structure. Finally, the documents are created on the target system via the API. All settings and configurations of the new application are adopted in this case. The target system now needs to be able to execute all business rules of the new system such as granting access permissions, insertions in folders, requests for renditions, etc., instead of the migration script or tool. For example, the first version of a document with the status listed as ‘superseded’ in the legacy system needs to pass through all status levels until reaching ‘approved.’ Then if the next migrated version bears the status ‘approved’, the first version is transferred to the ‘superseded’ status in the new system, as well.
I would like to stress the fact again that the logic and configuration of the new application ensures that the data structures are correct in this migration approach. The migrated documents will be treated as if they had been created in the new system originally, where you can continue to use them as before.