+

Search Tips   |   Advanced Search

What is new for migration

WebSphere Application Server v9.0 introduces several key enhancements to the migration tools.

Clone migration: Migrate and keep our old profile functional

We can now migrate the configuration to v9.0 and continue to use the previous version profile, which is known as a clone migration. Clone migrations follow the standard migration procedures, except specified the -clone parameter when we run the WASPostUpgrade command. If we clone a deployment manager, we must also clone its federated nodes.

For clone migrations, the new profile configuration must use unique port numbers so that the new and old configurations do not have port conflicts. Additionally, when we migrate a federated node, specify the v9.0 deployment manager host name and SOAP or RMI port.

Clone migrations on WAS for z/OS are supported on fix pack 9.0.0.3 and higher.

Define migration options with a properties file

Rather than specifying individual parameters on migration commands such as WASPreUpgrade and WASPostUpgrade, we can specify the -properties file_name.properties parameter to input a properties file. The properties file contains the following properties:

  • Migration parameter properties: These properties are equivalent to the parameters specified for the migration commands. Not every command-line parameter can be specified as a parameter property; limitations are noted in the template migration.properties file.
  • General tracing and debugging properties: These properties control tracing and debugging when the migration commands call external tools. For example, we can enable or disable trace and specify trace strings and locations.

A template migration.properties file is located in the app_server_root/properties directory. The template contains instructions and examples for defining properties. After you copy the file to a new location, modify the file to suit our migration. Use the same file for all profile and migration types because any properties that do not apply are ignored.

For more information about using the properties file, see Define our migration through properties.

Improved port assignment

The WASPostUpgrade -replacePorts and -portBlock parameters were replaced by the -setPorts and -resolvePortConflicts parameters respectively. These new parameters provide better clarity and flexibility to how the migration tools assign port values in the new configuration.

With the -setPorts parameter, we can choose from the following options:

  • Use the values from the old configuration

  • Use new values generated by the migration tools

  • Assign all ports, starting at a value specified

With the -resolvePortConflicts parameter, we can choose to resolve port conflicts by incrementing from the conflicting value or from a value specified.

The default port value for any new endpoint address is retrieved from a profile template and is checked for conflicts.

See WASPostUpgrade command.

Integrated Compute Grid migration

Previously, Compute Grid or Feature Pack for Modern Batch on WAS was migrated to a new version using the migrateConfigTo85.py script.

Instead of using this script, Compute Grid is now migrated as part of the standard migration processes, such as the Configuration Migration Management Tool or WASPreUpgrade and WASPostUpgrade commands.

Integrated WebSphere Virtual Enterprise and Intelligent Management migration

In WAS v7 and v8, WebSphere Virtual Enterprise was installed as a separate product on top of WAS. In WAS v8.5, WebSphere Virtual Enterprise was included in the WAS product as Intelligent Management.

WebSphere Virtual Enterprise and Intelligent Management previously required the VEUpgrade command to migrate artifacts to the new WAS cell. Instead of using this command, the artifacts are now migrated as part of the standard migration processes, such as the Configuration Migration Management Tool or WASPreUpgrade and WASPostUpgrade commands.

WASMigrationAppInstaller application installation tool

Use the WASMigrationAppInstaller command to migrate applications from the previous release into the new release. The tool is intended to replace the install_all_apps.jy script.

The WASPostUpgrade command also attempts to migrate the applications to the new release. If the only problems that occur when running the WASPostUpgrade command were with installing applications, run the WASMigrationAppInstaller command instead of rerunning the WASPostUpgrade command.

The tool installs only applications that are not already installed, so we can run the tool as many times as needed.

See WASMigrationAppInstaller command.

Deprecated, stabilized, and removed features

Changes in the v9.0 release include many deprecated, stabilized, or removed features, as well as some change in default value and behavior. These changes might affect our WAS environment and require modifications.

For a list of these changes, see What has changed in WAS.