Perform a Custom Migration
1. On the machine that hosts the new Integration Server, open a command window or shell and go to the new_Software AG_directory\IntegrationServer\bin\migrate directory.
2. Run the command migrate.{bat|sh}.
3. The utility asks for the full path to the Software AG directory that contains the old Integration Server installation or the ZIP file you made earlier.
4. 9.6, 9.7, 9.8, 9.9, or 9.10 upgrade: If the old Integration Server installation has more than one server instance, the utility asks which instance to migrate and lists the instances in the old installation.
The utility then asks for the name of a new instance to be the target of the migration. If you want the utility to migrate to the new instance that was created during installation, enter the name of that instance. If you want the utility to create a new instance and migrate to the new instance, enter a name that does not exist in the new installation.
If Wm packages exist on the old instance, and the same Wm packages exist in the new package repository, the utility will install those Wm packages from the new package repository on the new instance. If language packs exist in the package repository, the utility will install those language packs on the new instance.
5. The utility asks whether to import migration settings. Enter N.
6. The utility asks whether to migrate custom packages. If you choose to migrate all custom packages, the utility migrates the following:
Custom packages.
The WmChemPayloads, WmPapinetPayloads, WmRNPips, WmFINMessages, and WmFIXMessages packages, if present. These packages contains IS documents for the corresponding eStandards Modules and the schemas for those documents.
If you choose to migrate selected packages only, the utility lists each of the packages above and asks whether to migrate it.
7. The utility asks whether to migrate the password store.
8. The utility asks whether to migrate Integration Server configuration files. If you choose to migrate selected configuration files only, the utility lists each configuration file and asks whether to migrate it. There are about 50 configuration files.
9. The utility asks you to specify the behavior to use for new properties that have been added to the new Integration Server and existing properties that have new defaults in the new Integration Server. If you choose to specify the behavior to use, the utility lists each property and asks whether to use new behavior or preserve existing behavior. You can also read about these properties in the Integration Server readme.
10. The utility asks whether to migrate the functional aliases and the database drivers for the instance.
11. The utility asks whether to migrate the JDBC connection pool configurations for the instance. If you enter Y, the utility asks whether to use the live database or a cloned database with each migrated connection pool. If you respond that you are using a cloned database, the utility asks for the database URL, user name, and password.
12. If the Integration Server hosts Wm packages, the utility asks whether to migrate the configuration files for those packages. Examples of hosted Wm packages are ActiveTransfer (WmMFT), Mediator (WmMediator), Process Engine (WmPRT), adapters, and eStandards Modules.
13. 9.5, 9.6, 9.7, 9.8, 9.9, or 9.10 upgrade: The utility asks whether to migrate custom jar files. If you choose to migrate selected custom jar files only, the utility lists each custom jar file and asks whether to migrate it.
14. If the Integration Server hosts Trading Networks, the utility asks whether to migrate Trading Networks information. If you enter Y, the utility asks the following:
a. Whether to migrate the Trading Networks configuration file. If you enter Y, the utility copies the configuration properties from the old Trading Networks installation directory, adds them to the new configuration properties in the new Trading Networks, and replaces the properties.cnf file in the new_Software AG_directory\IntegrationServer\instances\instance_name\packages\WmTN\config directory.
b. Whether to migrate Trading Networks data. This migration maps the data in the Trading Networks database to the new table structure.
Note: | If you have a cluster of Trading Networks instances, the data is shared by all instances, so only migrate the data for one instance. |
c. Whether to migrate Trading Networks dashboard data. If you enter Y, the utility purges records from the dashboard tables and populates records from BIZDOC tables into dashboard tables. The dashboard tables include TransactionSummaryData, CustomAttributeVolumeValue, TransactionSuccessFailedData, SuccessFailedChartDocIdMap, and TransactionLateFAData.
15. The utility asks whether to export your settings. If you want to perform other migrations by importing the settings from this session, enter Y. If not, enter N.
