Perform a Custom Migration

1. On the machine that hosts the new installation, open a command window or shell and go to the new_Software AG_directory/IntegrationServer/bin/migrate directory.

4. If the old installation has more than one server instance, the utility asks which instance to migrate and lists the instances in the old installation.

For Integration Server, the utility then asks for the name of an instance to be the target of the migration. If you want the utility to migrate to the new instance that was created during installation, or to a new instance you created after installation, enter the name of that instance. If you want the utility to create an instance and migrate to this 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.

6. The utility asks whether to migrate custom packages. If you choose to migrate selected packages only, the utility lists each of the packages above and asks whether to migrate it. If you choose to migrate all custom packages, the utility also migrates the WmChemPayloads, WmPapinetPayloads, WmRNPips, WmFINMessages, and WmFIXMessages packages, if present, for Integration Server. These packages contain IS documents for the corresponding eStandards Modules and the schemas for those documents.:

8. The utility asks whether to migrate the Integration Server or Microservices Runtime 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.

Important:
During installation of the new Integration Server or Microservices Runtime, you specified a custom password as the default for the product. If you want to use this custom password, choose to migrate selected configuration file only, and do not migrate the users.cnf file. If you migrate users.cnf, the new customer password will not be available, and instead the password you used with the old Integration Server or Microservices Runtime will be in effect for the new product.

9. The utility asks you to specify the behavior to use for new properties that have been added to the new installation and existing properties that have new defaults in the new installation. If you choose to specify the behavior to use, the utility lists each property and asks whether to use the new behavior or preserve existing behavior. You can read about these properties in the Integration Server or Microservices Runtime readme.

For CloudStreams, select the new behavior asNeeded for the watt.server.http.listRequestVars property.

10. The utility asks whether to migrate functional aliases, database driver configurations, and JDBC connection pool configurations. If you enter Y for JDBC connection pool configurations, 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 for the migrated connection pool, the utility asks for the database URL, user, and password.

11. If the Integration Server or Microservices Runtime hosts Wm packages, the utility asks whether to migrate the configuration files for those packages. For some products, you might see additional prompts for migrating other data.

12. 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.

13. 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.

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. for Integration Server, the utility asks whether to migrate Java Service Wrapper customizations you made in the old custom_wrapper.conf files, if any. These are migrated to the new custom_wrapper.conf file.

16. The utility asks whether to update the host name in your database tables. If the old and new installations are on different machines, respond Y.

17. 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.

Note:
When cloned database configurations are provided, out of security concerns the cloned database password is not exported into the settings. If you do not continue the migration, you must specify cloneDbPassword in the command line when you use the custom settings to perform a migration.