Configurations, Data, and Assets that Can or Will be Migrated
You can choose whether to migrate the following:
Custom (user-created) packages.
Password store, and passwords.
Configuration files for
Integration Server or
Microservices Runtime, hosted products such as
Trading Networks or
CloudStreams, and hosted Wm packages that are also hosted on the new
Integration Server or
Microservices Runtime.
JDBC connection pool configurations, database drivers, and functional aliases.
Starting in 9.5, custom (user-created) jar files.
For
Integration Server, JAAS configuration files.
For
Integration Server, Java Service Wrapper customizations you made in the old custom_wrapper.conf files, including #include directives and comments (but not associated properties).
The utility will also do the following:
If you are upgrading
CloudStreams, migrate configuration artifacts related to administering
CloudStreams Server.
If the old installation used the embedded database, copy database tables from the old installation to the new installation and upgrade the tables to the new format, if the format has changed.
Update the SERVER ID stored in database tables and configuration files to reflect the new host machine.
Update keystore aliases of type PKCS12 whose keystore provider name is SunJSSE to use Bouncy Castle as a provider.
Add a new property named "Validate schemas using Xerces" to existing Web service descriptors, and set the new property to the same value to which the watt.server.wsdl.validateWSDLSchemaUsingXerces parameter was set in the old installation. The new property replaces the functionality provided by that parameter. For more information, see
webMethods Service Development Help.
If you are migrating Business Rules data, upgrade Business Rule projects. You might see XML parsing messages due to a Java bug; you can ignore these messages.
After the migration, the utility deletes old configuration files, and deletes old properties that are not used by the new installation from the new configuration files.