Prepare the Old Installation
1. Start and connect products.
a. Start the old Integration Server or Microservices Runtime and open the old Integration Server Administrator or Microservices Runtime Administrator.
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.
3. Suspend triggers and drain queues.
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.
c. Go to the Messaging > webMethods settings page. Make sure the CSQ Count field shows 0 for the Universal Messaging connection alias.
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.
4. This guide refers to different types of packages for Integration Server or Microservices Runtime. You might need to adjust your custom packages.
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>).
Note:
To simplify future upgrades, and as a general best practice, do not use the naming convention Wmname for custom packages.
5. Upgrade from 9.9, 9.10, or 9.12 for ActiveTransfer: Install Fix 11.
Note:
The ActiveTransfer release number in those releases was 9.8.
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.
7. Shut down the old installation.
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.
b. On the product’s old machine, open a command window or shell.
c. Go to the Software AG directory that contains the old product and enter this command:
jar cfM ZIP_file_name.zip *
d. Copy the product’s ZIP file to any directory on the machine that hosts the new product.
Important:
If using FTP to copy, use the binary file transfer mode\type. If you use another mode\type, the ZIP file might become corrupted.