Migration Options

A couple of notable migration options are available with Data Migration Tool (DMT).

Usually, DMT migrates the most relevant data objects (see Data that is not migrated or modified during migration). You can explicitly specify the object types that you want to migrate to do the migration in chunks.

This can be especially useful if you need to migrate a lot of data. If the migration process fails or is aborted, you usually need to repeat the complete process, since DMT cannot resume an aborted process and continue from where it left off.

The Migrate the following objects option allows you to specify the object types to migrate:

• All objects. DMT will perform a full migration of all supported data objects. This is the default setting.

• Base and user objects. Migrate base and user data objects. This includes base data objects that have no dependencies and base data objects that depend on user data objects, such as reports, report formats, and report fields.

• Base objects that have no dependencies. Migrate only base data objects. Base objects are objects that may be required by other objects, but don't depend on other objects. These include global configuration data, domains, organizational units, back-end servers, policies, and client components.

• User objects. Migrate only user data objects, i.e. users and user attributes. This also includes base data objects that depend on user data objects, such as reports, report formats, and report fields.

  This setting assumes that the base data objects were already migrated. Otherwise, the migration will fail due to missing dependencies.

• DIGIPASS objects. Migrate only authenticator data objects, i.e. authenticators, authenticator applications, and software authenticator parameters.

  This setting assumes that the base and user data objects were already migrated. Otherwise, the migration will likely fail due to broken authenticator assignments.

Reset All DIGIPASS Applications

This option resets authenticator records during migration. You need to enable this option if the system clocks vary between the source server and the destination server. The time zone settings must be correct on the destination server, and the clocks of the source and destination servers must be synchronized.

Small time variations will generally not matter as the Time Window functionality will tolerate minor variation and re-synchronize the authenticator application. For more information about time windows, refer to the respective product documentation for your products.

Update existing records

The Update existing records option allows you to specify how DMT should handle source records that already exist in the data destination:

• Update the existing records with the migrated data. This is useful, for instance, if you resume a previous migration that prematurely failed or was aborted.

• Leave the existing records and migrate only records that do not exist in the destination environment.

  Note that duplicate objects that are not replaced will be reported as warning in the migration summary.

Update license information

The Update license information option allows component licenses to be migrated with their component records. This option is only available, if you enable the Update existing records option.

If the Update license information option is enabled and a component record exists on the destination server with a valid license, the license on the destination server will be overwritten. This may cause a valid license to be replaced with an invalid license.

Test migration

You can test your migration to identify potential problems before you run the actual data migration. When the Test migration option is enabled, DMT obtains data from the source product, translates it to the correct format, and connects to the destination product. However, it does not write any data to the destination product.

You should be aware of some limitations when migrating data with Data Migration Tool:

• If the source system is not taken offline during the (test) migration, some changes made on the source system during the (test) migration will be omitted from the migration and will not appear on the destination system.

• Changes made on the source system after completing the (test) migration will not appear on the destination server automatically. There is no connection between the data stores. If changes are made on the source system, they need to be made on the destination system as well.

• Data Migration Tool does not allow data migration if maker–checker authorization is enabled on either the source or the destination system. Both, the source and the destination system need to have maker–checker authorization disabled.

• Replication

  Do not set up replication between the source and destination data stores.

Perform Windows name resolution

If you enable the Perform Windows name resolution option, the Windows user's SAM-Account-Name attribute and the FQDN for the user's domain will be looked up for each user ID in the master domain of the source database:

• User accounts that are not located in the master domain will not go through the translation process, as it is assumed that the user accounts are already in the correct domains.

• Name translation will still occur for user accounts in the master domain if the user ID does not have a domain qualifier (user@domain or DOMAIN\user). If the same user name exists in multiple domains, the first user account will be used and a warning will be entered in the log file.

• If the name translation process cannot find the global catalog or a domain controller, the error will abort the migration to allow you to resolve the connectivity problem. If translation fails for a specific user because the respective user account cannot be found, that user account will be skipped and migration will continue with the next user.

If you disable the Perform Windows name resolution option, each user ID will be copied as it was stored in the old database. User accounts will be assigned to the same domain and organizational unit as in the source database.

Change Master Domain name to

If the master domain name is different between products or locations, DMT can change the domain for any user accounts in the old master domain to the new master domain in the destination server during migration.

It is important to use the correct letter case when the Change Master Domain name to option is used during data migration. If an incorrect letter case is used, authenticator migration and assignment fails with a decryption error. In addition, the Change Master Domain name to option can only be used for the master domain.

Number of parallel reader/writer threads

DMT can use parallel threads to read the data from the source server and write it to the destination server.

The default numbers of used reader threads and writer threads are set to half of the number of CPU cores. DMT uses the calculated number of threads to read data records from the data source in batches and to write data items to the destination server. To improve data migration performance, you can change the number of threads to read and write more data in parallel.

Note that DMT reads data records from the data source, but writes data items to the destination server. This means that, if required, DMT handles interdependent data records and writes them to the destination server in one go, instead of writing individual data records. For example, an authenticator and all its authenticator applications is handled as one data chunk, although they are stored as separate data records in the data store.

If you are using a DIGIPASS import file as the data source, you cannot use more than one reader thread.

Since writing data is usually slower than reading, we recommend to use more writer threads and fully use the processor resources of the destination server.

Tracing

Tracing can be enabled for data migration and can be useful for troubleshooting. Tracing information is saved to a text file specified before you start the data migration.

If your organization is impacted by the General Data Protection Regulation (GDPR), you need to ensure that GDPR-compliance is met by encrypting the folder or disk storing the trace file, if tracing is used.

For more information on GDPR, refer to the OneSpan Authentication Server General Data Protection Regulation Compliance Guide.

Two levels of tracing are available for each migration:

• Basic Tracing. This will record the following information:

  • Critical error/warning [CRITC]

  • Major error/warning [MAJOR]

  • Minor error/warning [MINOR]

  • Configuration [CONFG]

  • Alert [ALERT]

  • Informational [INFO]

• Full tracing. This will record the following information:

  • Critical error/warning [CRITC]

  • Major error/warning [MAJOR]

  • Minor error/warning [MINOR]

  • Configuration [CONFG]

  • Alert [ALERT]

  • Informational [INFO]

  • Verbose informational messages [VINFO]

  • Data store access [DATA]