Executing the Migration Script

Prerequisites

All databases (cache, repository, and logging) are started successfully on the destination system.
All minimum hardware requirements are met.

When migrating, almost all processes, artifacts, and configurations created in the source system are either taken over into the target system or are adjusted there:

System configuration

For example, Integration Server configuration, custom plug-in configurations, custom libraries, drivers, Repository, certificates in the Key Manager, watch dog processes of the Connection Manager, application profiles, files related to the portal server and settings of the portal server
Users

For example, users, user groups, process roles, diagrams and modules
Operating states

For example, activation states of workflows and system connectors, process status data (waitings like timeouts, tasks and task list, queued processes, retries), the complete monitoring database as well as current workflow ID
Process states

Migrating from INUBIT 6.1/7.1: Workflows in the status Error, Waiting, Retry, Suspended, Processing, or Queued are migrated.
Process Id range
User data
- Tasks and task lists.
- As of INUBIT 6.0, the version history of user-specific Repository data is migrated.

The portal folder <inubit-installdir>/inubit/server/ibis_root/conf/portal is not backed up during the backup because restoring these versions will restore old versions that are incompatible with the installed portal version. This requires additional time and archiving effort. Hence, the portal folder of the target system is retained during migration.

Whether components are migrated and which manual steps are required, refer to Overview.

Proceed as follows

The activation states of workflows in the source system are passed to the target system when migrating. If necessary,adjust the states according to the requirements of the target system.
Ensure that the database drivers used on the source system are available in the <inubit-installdir>/inubit/server/process_engine/lib directory.
Optionally: When using the X.400 SE Connector install the Isode library on all X.400 clients.

Refer to the Thirdparty components for the Isode versions that support the INUBIT server.
Activate the maintenance mode on the Process Engine at the destination system to put the destination system into operation stepwise after being migrated.
Stop both the Process Engine of the source and the target system.
In the target system, navigate to <inubit-installdir>/inubit/bin/migration/ and call up the migration script migration.bat or .sh.

Usage

The migration script can be executed with two different input sources:

Providing a backup ZIP file (created by using the INUBIT backup script or Backup Connector)
```
migration.sh /path/to/backup.zip
```
Providing the path to an existing INUBIT installation, pointing to the Process Engine directory:
```
migration.sh /data/old_inubit/server
```
If the path contains blanks, you must enclose the path in single quotes (under Windows: double quotes), for example:
```
migration.bat "C:\old inubit\server"
```

If you have enhanced the system backup archive manually to migrate also the EDI ID lists (refer to EDI Migration), transfer the customized archive to the destination system and add the full archive path name as call parameter for the migration script, for example: migration.bat C:\tmp\inubit\backup.zip

Depending on the amount of module data, ensure that enough memory is available. For this purpose, modify -Xmx value, for example, to 20GB (20480M). Additionally, you should enable Concurrent Mark Sweep GC before executing the migration script by adding the ‑XX:+UseConcMarkSweepGC option to the command line call.

Option to limit the amount of versions to migrate

If you use the optional parameter -rv <versions_to_retain> or -recentVersionToRetain <versions_to_retain> you define with the numeric value <versions_to_retain> how many of the latest versions of workflows or modules shall be migrated, that is, are retained. Then, former versions of workflows and modules are skipped during the migration.

By default, all versions are migrated. Same happens if <versions_to_retain> is 0 or less.

If a workflow or module has less than <versions_to_retain> versions then they all are migrated. The head version is always migrated.

The numbering of versions remains the same after the migration; version increment will be continued at the highest version number.

Migration report

During the execution of the migration script, a migration report is generated as an HTML file migrationreport-<timestamp>.html inside migration directory /bin/migration/reports. It contains the migration results in both cases success and failure.

Example: /bin/migration/reports/migrationreport_2019.11.15_11.12.53.html

If you cancel the migration, modifications that have already been carried out on the target system are not rolled back. You can restart the migration later without any further steps.

If the migration script stops backing up under Windows because of locked library files, do one of the following steps:

Do a system backup with the Backup Connector and use the generated ZIP file for the migration.
Manually remove the libraries (jar files) from the source system and re-insert them in the target system after the migration.