Prepare the Old Installation

b. If you are using Universal Messaging, make sure Integration Server or Microservices Runtime is connected to each Universal Messaging server that is acting as a webMethods Messaging provider. If you are using another JMS provider, make sure Integration Server or Microservices Runtime is connected to the JMS provider.

2. If you have added any third-party (custom) jar files (for example, MySQL database driver jar files) to the old_Software AG_directory/IntegrationServer/lib/jars/custom or old_Software AG_directory/IntegrationServer/instances/instance_name/lib/jars/custom, make sure those jar files are compatible with new Integration Server or Microservices Runtime.

a. Go to the Server > Quiesce page. Click Enter Quiesce mode and set the time for the quiesce to occur to at least 1 minute, so Integration Server or Microservices Runtime has time to stop executing new incoming requests and to finish executing in-flight services. Make sure the Quiesce Report shows the status SUCCESS in every field. For instructions and details about specific actions that occur when Integration Server or Microservices Runtime is quiesced, see webMethods Integration Server Administrator’s Guide.

b. Go to the Messaging > webMethods triggers page. If the Current Queue Counts field does not show 0 for every trigger, diagnose and fix the problem (for example, the webMethods Messaging provider might not be active or might be slow to process requests from Integration Server or Microservices Runtime). Refresh the page until the Current Queue Counts field shows 0 for every trigger.

d. Go to the Messaging > JMS settings page. In the JMS Connection Alias Definitions area, make sure the CSQ Count field shows 0 for every JMS connection alias.

Hosted packages. These are packages provided by Software AG on the Software AG Installer, where they are listed under Integration Server or Microservices Runtime on the product selection tree. On the tree, they are listed using their product names. However, in the file system and within Integration Server or Microservices Runtime, they are listed under their package names, and those names start with Wm. For this reason they are also called Wm packages. Examples of hosted Wm packages are ActiveTransfer (WmMFT), Process Engine (WmPRT), Trading Networks (WmTN), adapters, and eStandards Modules.

Custom packages. These include Integration Server or Microservices Runtime packages created by users in Software AG Designer and business process packages generated by Integration Server users from Software AG Designer. The migration utility will scan the old installation for custom packages. However, it will not find custom packages whose names start with Wm, as this naming convention is used for packages provided by Software AG. If you have custom packages whose names start with Wm, and you want to migrate them, go to the new_Software AG_directory/IntegrationServer/bin/migrate directory, open the packages.cnf file, and add a <value name><\value> tag that identifies those custom packages (for example, <value name="WmFINMessages">WmFINMessages</value>).

When you migrate ActiveTransfer from version 10.11 or lower to version 10.15, you must also migrate My webMethods Server to version 10.15. For more information about how to migrate My webMethods Server, see Migrate My webMethods Server.

For ActiveTransfer versions 9.9, 9.10, or 9.12, install Fix 11.

6. If the old Integration Server or Microservices Runtime hosts a Process Engine, install the latest product fixes on the old Process Engine, then start the old Process Engine.

If the product is running	Take this action...
As a Windows service	Shut down from the Windows Services window. Services are listed as Software AG product release.
As a Windows application	Shut down from the Windows start menu. Applications are listed as Software AG > Stop Servers > product .
On a UNIX system	Use the shut down instructions in the product documentation for your old release.

Note:
It is especially important to shut down all old ActiveTransfer, Integration Server, and Microservices Runtime instances that connect to database components you are going to migrate.

8. If your old and new installations are on different machines, create a ZIP file of the old product installation to use as the migration source. The instructions in this section use the Java Archive tool to create the ZIP file. Specify the location of the Java Archive tool in the JAVA_HOME and PATH system variables on the machine that hosts the old product installation. The tool is located in the Software AG_directory/jvm/jvm/bin directory. On some systems, the lower-level jvm directory name includes additional information, such as /jvm/jvm160_32, or /jvm/jvm170, or /jvm/jvm_64.

a. For Integration Server, you can reduce the size of the ZIP file by first moving the log files out of the old_Software AG_directory/profiles/instance_name/logs, /IntegrationServer/instances/logs, and /IntegrationServer/instances/instance_name/logs directories.

Upgrade from 10.3 or earlier: For Microservices Runtime, you can reduce the size of the ZIP file by first moving the log files out of the old_Software AG_directory/profiles/instance_name/logs, /IntegrationServer/instances/logs, and /IntegrationServer/instances/instance_name/logs directories. For release 10.4 and later, you can reduce the size of the ZIP file by first moving the log files out of the /IntegrationServer/logs directories.