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 Liferay 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/libdirectory. -
Optionally: When using the X.400 SE Connector install the Isode 16.2v1 library at all X.400 clients.
-
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 scriptmigration.bator.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/serverIf 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: |
|
Depending on the amount of module data, ensure that enough memory is available.
For this purpose, modify |
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.
Option to keep portal server configuration on target system
Use the optional parameter --sprtl or --skipConnectingSourceLiferayPortal to prevent the migration script from connecting to the former Liferay portal.
If this parameter is used, the migration script tries to retain both portal server configuration and process user server configuration as it is on the target INUBIT system.
|
If both the portal server and the process user server are not configured on the target INUBIT system, the migration script displays a warning message. The migration script continues with the default behavior meaning that it uses the configuration provided in the system backup archive, afterward. |
|
This feature does not imply the Liferay portal server migration, it only takes care of the server configuration properties while migration so that while migration it is able to use the configuration details of the new Liferay instance. |
|
If you want to use a new Liferay portal server with a new INUBIT installation, refer to Using an Existing Liferay Portal With the New INUBIT 8.0 Installation. |
migration.sh /path/to/backup.zip {--sprtl|--skipConnectingSourceLiferayPortal}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:
|
