Technical Solution 

OpenMigrate’s framework is configurable, modular, and extensible, providing the capabilities to address both one-time and ongoing migrations with a flexible and high-performance architecture.  Developed by Technology Services Group for our ECM customers, OpenMigrate is our answer to the shortcomings of typical Documentum migration utilities.

How it Works

There are several OpenMigrate components.

1. Migration Engine – This component is the core of the product, initializing the infrastructure and controlling the flow of data from the source to the target.  The Migration Engine leverages XML configuration files to determine what transformations/mappings to apply to each object being migrated.  It is responsible for "asking" the Source to provide a Migration Node for each piece of content; the Mapping layer to manipulate and transform the Node; and the Target to write the Node to the target system.  The Migration Node is the heart of OpenMigrate's transaction model:  each node either completely succeeds or completely fails.  The configurable nature of OpenMigrate allows a Node to represent a single file, an entire version tree, or even an entire folder of files.
2. Source/Target Interface – This interface allows the migration engine to communicate to the source/target without understanding the specifics of the source/target implementation.  It enables the application to connect easily to many different source and target systems, including different software versions.  It utilizes XML configuration to determine which source/target it will connect to.
3. Source/Target Adapter (e.g., Documentum, File System, Alfresco, Centera, JDBC) – The adapter will directly communicate with the source/target that is being implemented.  Each adapter is written to interact with a specific piece of software (e.g., Documentum, file system, Alfresco.  For more information on our Alfresco solutions, visit ECM Management Systems with Alfresco).  The adapters leverage configuration files to determine how the data should be read, manipulated and written; and the Migration Queue to know which data should be extracted and populated into the target database.  Within each adapter, a Content Reader retrieves the actual content from the source system.
4. Migration Queue and Log – The Migration Queue is the application’s “to-do” list, responsible for informing the source and target adapters what to migrate.  It is also responsible for recording each object’s status (success or failure). The Migration Log serves as an audit trail providing a detailed mapping for each migrated object.  Like the rest of the system, these components are highly configurable, and the core implementations (JDBC via Hibernate, CSV files, even Excel via Jakarta POI) can be extended if needed.
5. Bulk Load Interface - Utilizing the powerful underlying engine in one of two configurations (File System to Documentum or Documentum to Documentum), the SpringMVC-based Bulk Load web application allows an end user simplified access to the power of OpenMigrate.  Using the streamlined interface, a user uploads a content file and associates it with a document type, then indexes it according to a configurable properties page.  Once the user has set up a batch, he or she can execute the import and observe its progress in real-time.