Skip to main content Skip to complementary content

Using the dbmigration tool for migration

The dbmigration tool allows you to migrate system objects, data records and deployed objects (except Jobs) between relational databases.

Before you begin

  • Make sure that both MDM servers are up and running.

  • If you need to migrate between two databases on a single machine, you must run the two MDM servers side by side. You can do this by setting a different port binding on the target server.

  • The migration of UpdateReport records to the target MDM server may lead to unexpected results. For example, some eligible triggers are triggered, or processes or Jobs are executed. To avoid this issue, before the migration, you need to disable the Event Manager on the target MDM server by configuring subscription.engine.autostart=false in the file <$INSTALLDIR>\conf\mdm.conf where <$INSTALLDIR> specifies the MDM server installation directory. You need to re-enable it and when the migration is completed. Make sure to restart the MDM server for the configuration to take effect.


  1. In the target MDM server, browse to the <$INSTALLDIR>/tools/dbmigration folder.
  2. Save a copy of the file giving it the name, for example.
  3. Open the new file using a text editor.
  4. In the from list, set the connection information to the source server and in the to list, set the connection information to the target server.
    If you want to migrate from 5.X, one configuration example is given below:
    ####from 5.X using EJBs####
    If you want to migrate from 6.X, one configuration example is given below:
    ####from 6.X using REST####
    If the data containers and data models in your source server do not have the same names (for example, if the ProductDemo data container uses the Product data model), you must also use the following syntax in the file to specify how they are connected: <data container>.datamodel=<datamodel>. For example: ProductDemo.datamodel=Product
    Information noteNote: For entities that have Foreign Keys to themselves (for example, Person might have a FK relation 'is child of' to Person), the migration process does not ensure the correct insertion order. As a result, the validation of such records may fail even though data integrity is correct. To avoid this, it is recommended that you deploy the data model to the target MDM server first and then temporarily disable FK integrity checks for the FK field in the data model editor.
  5. If needed, modify the number of migration threads specified by the parameter db.migration.threads.
    The default value of this parameter is 8.
  6. Run the appropriate dbmigration file for your system and give the command line the file name you set as a parameter, as follows:
    • On Windows: dbmigration.bat
    • On Linux:
  7. If needed, you can add parameters to the command line when running the dbmigration script for your system.
    Add the parameter... To...

    Do the migration in an interactive mode.

    For example, you will be prompted which data model needs to be migrated. Enter Y to select the data model you want to migrate, or enter N to skip the data model you do not want to migrate.


    Perform only the validation of user-defined data models.

    You will be prompted if a data model has any entity that refers to itself, or has circular dependencies between entities such as EntityA references EntityB, EntityB references EntityC, and EntityC references EntityA.

  8. Restart the target server in order to complete the migration process. If the source and target servers are running on the same machine and using different port bindings, stop the source server and then launch the target server on the desired port.


This will migrate the MDM instances stored in databases from the source server to the target server in line with the connection information defined in the file.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!