Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
AIP - Archival Information Package
AIU - Archival Information Unit
BLOB - Binary large object
DB - Database
CSV - Comma separated values
CLOB - Character large object
DCTM - Documentum
DFC - Documentum Foundation Classes
DMS - Document Management System
DSS - Data Submission Session
GB - Gigabyte
GHz - Gigahertz
IA - InfoArchive
JDBC - Java database connectivity
JRE - Java Runtime Environment
JVM - Java Virtual Machine
KB - Kilobyte
MB - Megabyte
MS - Microsoft
MHz - Megahertz
RAM - Random Access Memory
regex - Regular expression
SIP - Submission Information Package
SPx - Service Pack x
SQL - Structured Query Language
XML - Extensible Markup Language
XSD - File that contains a XML Schema Definition
XSL - File that contains Extensible Stylesheet Language Transformation rules
Migration Set A migration set comprises a selection of objects (documents, folders) and set of rules for migrating these objects. A migration set represents the work unit of migration-center. Objects can be added or excluded based on various filtering criteria. Individual transformation rules, mapping lists and validations can be defined for a migration set. Transformation rules generate values for attributes, which are in turn validated by validation rules. Objects failing to pass either transformation or validation rules will be reported as errors, requiring the user to review and fix these errors before being allowed to import such objects.
Attribute A piece of metadata belonging to an object (e.g. name, author, creation date, etc.). Can also refer to the attribute’s value, depending on context.
Transformation Rules A set of rules used for editing, transforming and generating attribute values. A set of transformation rules is always unique to a migration set. A single transformation rules is comprised of one or several different steps, where each step calls exactly one transformation function. Transformation rules can be exported/imported to/from files or copied between migration sets containing the same type of objects.
Transformation Function Transformation functions compute attribute values for a transformation rule. Multiple transformation functions can be used in a single transformation rule.
Job Server The migration-center component listening to incoming job requests, and running jobs by executing the code behind the connectors referred by those jobs. Starting a scanner or importer which uses the Documentum connector will send a request to the Jobserver set for that scanner, and tell that Jobserver to execute the specified job with its parameters and the corresponding connector code.
Transformation The transformation process transforms a set of objects according to the set of rules to generate or extract.
Validation Validation checks the attribute values resulting from the Transformation step against the definitions of the object types these attributes are associated with. It checks to make sure the values meet basic properties such as data type, length, repeating or mandatory properties of the attributes they are associated with. Only if an object passes validation for every one of its attributes will it be allowed for import. Objects which do not pass validation are not permitted for import since they would fail anyway.
Mapping list A mapping list is a key-value pair used to match a value from the source data (the key) directly to the specified value.
This online documentation describes how to use the migration-center software in order to migrate content from a source system into a target system (or into the same system in case of an in-place migration).
Please see the Release Notes for a summary of new and changed features as well as known issues in the migration-center releases.
Also, please make sure that you have read System Requirements before you install and use migration-center in order to achieve the best performance and results for your migration projects.
The supported source and target systems and their versions can be found in the Supported Version page.
Migration-center is a modular system th at connects to the various source and target systems using different connectors. The source system connectors are called scanners and the target system ones are called importers. The capabilities and the configuration parameters of each connector are described in the corresponding manual.
You can find the explanations of the terms and concepts used in this manual in the Glossary.
And last but not least, Legal Notice contains some important legal information.
Customized versions of connectors or entirely new ones (for other types of source and target systems) can be created and added to migration-center thanks to the open, API-based and documented architecture of the product. If such customized connectors are deployed in your migration project, the documentation provided with them should be consulted instead, since the features, behavior and parameters are likely to be different from the connectors described in these guides.
For additional tips and tricks, latest blog posts, FAQs, and helpful how-to articles, please visit our user forum.
In case you have technical questions or suggestions for improving migration-center, please send an email to our product support at support@migration-center.com.
A content migration with migration-center always involves a source system, a target system, and of course the migration-center itself.
This section provides information about the requirements for using migration-center in a content migration project.
For best results and performance it is recommended that every component will be installed on a different system. Hence, the system requirements for each component are listed separately.
Note that not all connectors are available on the Linux version of the jobserver.
Migration-center has 3 main components: Database component, WebClient and Jobserver component.
The Database stores all the migration-center configurations and all scanned and imported objects with their source and target metadata.
The Jobserver component receives the scan or import configuration from the Client and connects to source/target systems to extract/import objects, processes metadata into/from the Database and the content into/from the file system staging area. Multiple Jobservers can be installed.
For the following systems there are additional steps or components: Alfresco, Documentum, Domino/Lotus Notes, SharePoint, SharePoint Online.
Please refer to their respective user guides for the actual instructions.
The main migration-center components can be installed either on the same machine or on separate machines, by using the installers.
Starting with version 22.1.0 the Database installer no longer requires Oracle Client. The installer will connect to the database using JDBC.
The Jobserver installer can be run on a windows machine, but to actually start the Jobserver you need Java 8 or 11 installed. The Linux Jobserver does not have an installer, it has scripts to install the service.
The WebClient installer can be run on a Windows machine as well. It will deliver a customized Tomcat that is installed as a windows service.
The WebClient connects as follows:
- to the Browser via port 443 - to the Database using connection via information provided by the user (port 1521 by default) - to the Jobserver via port 9700 by default
The Jobserver connects as follows: - to the Database via JDBC connection on the same Oracle port as the Client - to each source or target system differently based on the system itself
When using the Scheduler feature the job will be triggered by the Database instance itself from the Database machine by sending a socket signal to the Jobserver via the defined port (9700 by default).
The general process of performing migrations with migration-center is done in several steps:
The Analyze phase involves configuring a Scanner to connect to a Source System, that will extract the metadata and save it as objects in the migration-center database, and export the content to a defined Filesystem location, which acts as a staging area.
The Organize phase involves assigning Scan Runs into Migration Sets, or migsets for short.
The next 3 phases, Transform, Validate and Correct, work together and involve creating Transformation Rules by which your Source Metadata is Transformed into Target Metadata. The metadata is assigned to Target Type definitions, which can be defined in advance. And based on those definitions the metadata is Validated. If the resulting target metadata is not the desired one, you can reset the objects and repeat the process by correcting or adding transformation rules.
The Import phase, is the last step, and involves creating an Importer, which will connect to the Target System, assigning a migset with Validated Objects to it and starting the import run. You can monitor the progress in the importer run history or directly in the migsets view.
All the migration phases can be done in parallel for different batches of documents that are migrated.
When you first access the link to the WebClient you will see a login window.
The default login user is fmemc
and the default password is migration123
.
If this is a fresh installation your Connection dropdown will be empty. You will need to configure a new connection to your Database.
This is done by going to the Manage Connections view and clicking Add Connection.
Here you will set a Connection Name and the Database Type, Host, Port and Service Name(database name) for the database you will be using. Click Create to create the connection and be able to use it when signing in.
Before you are able to run a scanner you first need to define a Jobserver by going to the Job Servers tab of the Configuration page.
Click the Add Job Server button and enter the Name, Location (hostname) of the machine where the Jobserver component is installed, and the Port (default is 9700). An optional description can also be added.
Avoid using localhost or 127.0.0.1 for the Jobserver location. That will cause issues when using the scheduler feature.
Open the Scanners page and click the Add Scanner button:
Fill in the Name of this scanner, select a type and select a Jobserver where you want this scan to run.
After you have filled at least the mandatory parameters of the scanner configuration you can save it by clicking on Save.
You can run it by clicking Save & Run in the toolbar, or by going back to the list of scanners and clicking on Start Scan Job in the Right Click context menu.
Clicking on History allows you to see a list of all Scan Runs performed by the this scanner configuration.
Clicking on Source Objects shows you the objects grid for this scanner or scan run.
Open the Migration Sets page and click the Add MigSet button.
Enter a name for this migset and select the Migration Path from the Type dropdown.
In the same view, under Available you will see the scan runs corresponding to your chosen migration-path. Select which scan runs you want to include in this migset by double clicking them or by using the down arrow button.
To actually get the objects locked in this migset you need to click on the Select Objects button
As an optional step before clicking on the Select Objects button, there are 2 filtering options:
Simple Filtering, where you can exclude objects based on their values:
Advanced Filtering, where you can create rules by which to select the objects:
With the Migset you have just created selected, click on the Transformation from the toolbar.
The Rules section in the top left corner lists the Transformation Rules created so far in this migset. You can create a new one using the New button. In the middle there's the Rule Properties section where you can specify the rule Name and if it should return multi-value results.
The Transformation methods section contains a dropdown of all the Functions that you can use inside your transformation rule. These functions take Source Attributes and static values to generate a new value as a Target Attribute. Multiple functions can be linked together by processing the result of a Previous Step:
As you can imagine this is the main strength of migration-center as it allows you to create very complex rules to ensure you get the required results in your Target System.
On the bottom left corner we have the Rules for system attributes. These function the same as the regular transformation rules, except they have a fixed name and therefore serve a specific purpose during the import. Please refer to the user guide of the Importer you are using for details on what each system rule does.
On the Associations tab of the Transformation view you can associate the previously defined Transformation rules to a Target Attribute of an object type.
The Types dropdown shows you a list of all Object Type Definitions in migration-center and you can select which ones are to be used in this migset. In the screenshot above we have selected opentext_document and opentext_rm_classification.
Clicking through the list of selected types will show, on the right side, the current associations between Rules and Target attributes.
The default system rule for specifying what Object Type to use is normally called target_type but differ in certain connectors (i.e. r_object_type in Documentum).
Rules that were not associated to any target attribute will NOT be migrated during the import
To mange the available object types in migration-center go to Configure -> Object Types
After you have finished writing the necessary transformation rules you can save the migset, and trigger Transformation on the migset. This will also apply Validation.
Transformation will apply the rules in the migset on each object individually and will generate the target objects. The objects will move to the Transformed state.
Validation will compare the generated values against the object type definition restrictions to ensure the values fit. If successful the objects will move to the Validated state.
The source metadata remains unchanged during the entire migration process and can be viewed in the Source Objects view
After doing the transformation, the Target Objects can be viewed in the Transformed Objects view.
If any issue occurred during transformation or validation, the objects will move to the Error state and can be checked in the Error Objects view.
Only objects that reached the Validated State will be processed by the importer. This includes objects which were validated and then marked as error during import.
Here is a diagram with all the states the Objects in migration-center can go through:
Open the Importers page and click the Add Importer button:
The Importers section is very similar to the Scanners one so we will only cover the differences.
After setting all necessary parameters for your import to function correctly you must go to the Selection tab which will allow you to select one or more migsets for import. After that you can save the importer and run it.
You can monitor the status of the import either in the the Jobs view, in the importer History or in the Migsets view. Each view will show the progress of the migration in varying levels of detail, with the migsets one showing the most details of the objects being imported.
When the import has finished you can see the status changed to Finished and all the objects marked as Imported. If any errors or warnings occurred you can view them either in the Error Objects view of the migset or by opening the import run log from the history of the importer.
You can automate the migration process from Scan to Import by using the Scheduler feature. This is very useful in setting up a continuous migration of active systems where the users are still modifying and creating documents.
How it works: You create a scheduled job and select existing valid scanner, migset and importer configurations. If the Scheduler is set to active and depending on what interval settings are set, the scheduler will automatically perform the following actions: - Start the scanner - Create a copy of your migset and assign the scanned objects to it - Run Transformation and Validation - Assign the migset to the importer - Start the importer - (optional) send an email report if configured
The types of the scanner, migset and importer selected in a scheduler must belong to the same migration path.
Create a new Scheduler and enter the Name and Description.
Here, you can also select your Scanner, Migset and Importer.
Next, on the Frequency tab, you have all the options to configure when your scheduled job will trigger and when it will stop triggering. Here you can also configure the email reporting feature.
You can click Save to save the Scheduler and it will start at the scheduled time.
If you open the History tab you can see the list of all runs of the scheduler along with some information about the status of each run.
The mapping lists are a simple and very powerful feature of migration-center. They can be used for a wide variety of scenarios.
A mapping list is just a collection of key - value pairs. A mapping list can also contain multiple values for one key. You can create one globally using the Configure -> Mapping List menu. This will make the mapping list available for use in any migset.
Or you can also create it directly in a migset for use only in that migset.
To use your created mapping list you must use the mapValue() function inside a migset's transformation rules.
The value to be transformed is matched with the values in the Key column of the mapping list. If a value is found then the function returns the equivalent value from the Value column. If the value cannot be matched or the source value is null, the function will trigger a Transformation error on the object or return an empty value (depending if Report missing values is set to 1 or 0).
Upgrading an older installation of migration-center usually consists the following steps:
Uninstall existing Client and Jobserver installations
Install the new version of Client and Jobserver from the new installation package
Upgrade the migration-center Database by running the Database installer against the existing instance
In this section we will cover only the Database upgrade. Instructions on uninstalling and installing the Client and Jobserver components can be found in the previous sections of this user guide.
You do not need a new license key when upgrading an existing installation. The installer will not ask you for a license key.
Upgrading migration-center will keep all existing configuration and data.
Please stop any running jobs (scanners, importers, schedulers, transformations, validations) before starting the upgrade.
A previous version of the migration-center database can be upgraded to the current version. The installer will detect supported database versions eligible for the upgrade and offer to upgrade the database structure, migration data and stored procedures to the current version.
To start the process simply start the Database installer of the new version of migration-center.
Enter the credentials for connecting to the old migration-center database. If the detected version of the database component is supported for upgrade, the following screen will appear:
Please backup your migration-center Database before upgrading it.
Enter a location for saving the database installation/upgrade log file. In case of any errors this log file will be requested by our technical support staff.
After clicking Install the appropriate database scripts will be executed.
An upgrade can take in excess of 1 hour to perform, depending on the amount of data and database system performance. This is normal and does not mean the installer has stopped responding. Please do not try to close the installer application or otherwise intervene in the process.
After the upgrade finishes you should see the Progress bar filled and the Finish button.
The migration-center database installer supports upgrading migration center databases starting with version 3.0.
The following conditions need to be fulfilled for the upgrade procedure to work (these are checked by the installer):
The old database’s version must be one of the following: 3.0.x, 3.0.1.985, 3.1.0.1517, 3.1.0.1549, 3.1.1.1732, 3.1.2.1894, 3.2.0.2378, 3.2.1.2512, 3.2.2.2584, 3.2.2.2688, 3.2.3.2808, 3.2.4.3124, 3.2.4.3187, 3.2.4.3214, 3.2.4.3355, 3.2.5.3609, 3.2.5.3768, 3.2.6.3899, 3.2.6.4131, 3.2.7.4348, 3.2.7.7701, 3.2.7.7831, 3.2.7.7919, 3.2.8.7977, 3.2.8.8184, 3.2.8.8235, 3.2.8.8315, 3.2.9.8452, 3.3.8573, 3.4.8700, 3.5.8952, 3.5.8952, 3.6.8970, 3.7.1219, 3.8.0125, 3.9.0513, 3.9.0606, 3.9.0614, 3.9.0606, 3.9.0704, 3.10.0823, 3.10.0905, 3.11.1002, 3.12.1219, 3.12.0226, 3.13.0403, 3.13.0416, 3.13.0508, 3.14.0630, 3.14.0807, 3.15.0930, 3.15.1023, 3.15.1218, 3.16.0331, 3.17.0630, 3.17.0810
Due to the new update feature released with migration-center 3.1.0, a new instance of an existing scanner may detect updates for objects scanned with previous versions even though the objects haven’t changed from the previous scan. This behavior always applies to virtual documents or documents that have dm_relations and occurs due to the information used by the new features in migration-center 3.1 not being available in the previous release. For this reason, a new scan will recreate this information on its first run.
Transformation rules created with a version older than 3.1.0 which use the system attribute r_folder_path might need to be reconfigured. This is because migration-center 3.1 now stores absolute folder paths instead of paths relative to “scanFolderPaths” as was the case with the previous versions.
Database upgrade from previous versions older than 3.1.2: as a result of the upgrade process increasing the default size for attribute fields to 4000 bytes (up from the previous 2000 bytes), Oracle’s internal data alignment structures may fragment. This can result in a performance drop of up to 20% when working with updated data (apparent when transforming / validating / resetting). A clean installation is not affected, neither is new data which is added to an updated database, because in these cases the new data will be properly aligned to the new 4000 byte sized fields as it is added to the database.
Due to changes and new functionalities implemented in migration-center version 3.2 that rely on additional information not present in older releases, the following points should be considered when updating a database to version 3.2 or later:
The concatenate function will only have 5 parameters for newly added transformation rules. Reason: the “Concatenate” transformation function has been extended to 5 parameters for version 3.2. Transformation rules using the “Concatenate” function and created with a previous version of migration-center will retain their original 3 parameters only.
The system rule “mc_content_location”, which allows the user to define or override the location where the objects’ content files are stored will be available for use only in migration sets created after the database has been upgraded to version 3.2 Reason: the “mc_content_location” system rule is new to migration-center version 3.2 and did not exist in previous versions
The Filesystem scanner won’t create the “dctm_obj_link” attribute anymore Reason: with version 3.2 of migration-center scanners and importers are no longer paired together. The “dctm_obj_link” attribute was created automatically by the Filesystem scanner in previous iterations because it was a Filesystem-Documentum connector. Since this no longer applies to the current Filesystem scanner which is just a generic scanner for filesystem objects and has no connection to any specific target system, it won’t create any attributes specific to particular target systems either. If objects scanned with a Filesystem scanner are intended to be migrated to a Documentum system, the “dctm_obj_link” rule must be created and populated with transformation rules in the same way as any other user-defined rule.
The Filesystem scanner won’t detect changes in a file’s metadata during subsequent scans for files which have been scanned prior to updating to version 3.2 Reason: detecting changes in a file’s external metadata (in addition to the file’s content) is a new feature of the Filesystem scanner in migration-center 3.2; previous versions of migration-center did not store the information which would be required by the current Filesystem scanner to detect such changes. A change to a file’s modification date would trigger the update mechanism though and would also enable full 3.2 functionality on subsequent scans.
The required capacities depend on the number of documents to be processed. The values given below are minimal requirements for a system processing about 1.000.000 documents. Please see the for more details.
For a typical Oracle Database creation please refer to . For more advanced topics regarding Oracle Database configuration and administration please refer to .
The WebClient is a web based UI where you can manage all the scanner, importer and migset configurations and you can trigger scan, import or transformation jobs. The WebClient can be installed on a machine in your network and then accessed from multiple other machines through a web browser (see for supported browsers).
This is just a quick overview of the installation process. For specific details please see and .
This will open Object Types view where you can create new Types and either manually adding each of the type's attributes or importing them from a CSV file. More details are in the .
Before upgradig highly recommended to backup the existing data as described in the section.
You can check your current database version in the Client’s “About” window. If your version is not one of the above please contact our technical support at .
If the database contains Virtual Documents and objects that are part of scanned Dctm Relations (this does not apply to the FileSystem connector) some additional checks are done by the installer. In case any of these checks fail an error is raised by the installer. In this case stop the installation and contact our technical support at .