Migration considerations

Before beginning process of migrating to WebSphere Application Server v9.0, there are some considerations of which we need to be aware.

Before performing the migration, evaluate the items deprecated in WAS v9.0.

High-availability manager (HAM) and core-group functionality are included in WAS v7.0 or later.

In most cases the recommended number of servers in a core group should not exceed 50. You receive a warning message when the migration tools add a server that exceeds the recommended upper limit.

The configuration migration tools do not convert applications or make them compatible with a new Java SDK level. Before migrating to a new Java SDK, use the WAS Migration Toolkit to evaluate the applications for any changes that we might need to make, and test the applications after making any required updates.

See Migrate API and specifications for more information.

The migration tools create a migration backup directory containing a backup copy of the configuration from the previous version, which is the size of the configuration directory and applications from the previous profile plus the trace files. In addition, the system must have space for the target profile, which after migration will be the same size as the source profile.

The amount of storage that the system requires for the backup directory depends on the environment as well as on the migration tool that we are using.

• Location: Backup directories as specified as parameters of the WASPreUpgrade and WASPostUpgrade commands
• Amount: For an estimate of our storage requirements when using these commands, add the following amounts.
  • Size of the following items for all of the profiles in the previous configuration:
    • profile_root/installableApps directory
    • profile_root/installedApps directory
    • profile_root/config directory
    • profile_root/properties directory
    • Shared libraries referenced in the libraries.xml configuration files
    • Resource adapter archive (RAR) files referenced in the resources.xml configuration files

  • If trace is enabled, allow enough space for the trace files, which depends on the size and complexity of the configuration.

If we use isolated data repositories-specifically, nonshared data repositories such as transaction logs for SIB and Apache Derby databases - and we migrate from a previous release, our existing databases and transaction logs are saved when the WASPreUpgrade command is run. Any database changes made after running the WASPreUpgrade command are not reflected in the migrated environment.

• If we have mission-critical information stored in these local data repositories, we should safely shut down all servers that interact with those repositories before attempting migration. Those servers should remain offline until the migration has been successfully completed or rolled back.

• If we make multiple attempts at migration, either because of unexpected rollback or to apply fixes, rerun the WASPreUpgrade command so any changes to the isolated data repositories are reflected in the migrated environment.

After the migration is complete or we have rolled back to the previous version, we can restart the servers that interact with these isolated data repositories.

Do not migrate a node with active servers if the SIB uses the file-store option for one or all of the messaging engines.

• (Windows) The WASPreUpgrade command fails with a file-locked exception when we try to copy the file stores on an active application server.

• (AIX) (Linux) The WASPreUpgrade command copies a locked file, which could compromise data consistency.

A data store for the messaging engine is an option for a hot migration; but if a file store must be used, the servers should not be running.

(Windows) If we try to run the WASPreUpgrade command to migrate from v6.1 with the node and application server that own the SIB file store still running, we might get an error similar to the following:

C:\was80A\bin>WASPreUpgrade c:\bkupWAS6.1.0.17June30B C:\was61B
IGR0385I: Starting to save profile AppSrv01.
IGR0215W: The migration function cannot copy the file and open the destination file c:\bkupWAS6.1.0.17June30B\migrated\C_\FSJune19\Log.
IGR0272E: The migration function cannot complete the command.

If we then shut down the application server and node, the WASPreUpgrade command completes.

Before migrating an Apache Derby database, ensure any application servers hosting applications that are using the Apache Derby database are closed. Otherwise, the Apache Derby migration fails.

We should be aware of the following rules related to migrating security domains:

• If we migrate a deployment manager that has a security domain with a cell-level scope, the migration tools take the following actions:
  • Migration creates a domain in the new configuration called PassThroughToGlobalSecurity if it does not already exist.

  • Migration adds a cluster mapping to the new configuration for all clusters that existed in the old configuration.
    • Clusters that only existed in the v9.0 deployment-manager configuration before migration do not have their mappings to PassThroughToGlobalSecurity changed.
      • If mappings for the v9.0 clusters exist before migration, they still exist after migration.
      • If no mappings for the v9.0 clusters exist before migration, they still do not exist after migration.

    • If a cluster exists in both the previous configuration and the v9.0 configuration before migration, the cluster in the new configuration is added to the PassThroughToGlobalSecurity domain and behaves like the cluster in the previous release.

  • Migration adds a bus mapping for any busses that exist in a migrated v6.1.x configuration.

    Bus mappings are updated following the same rules as those for cluster mapping.

  • Administrative servers (deployment manager) are not added to the PassThroughToGlobalSecurity domain.

  If we migrate a federated node that has a security domain with a cell-level scope, the migration tools take the following actions:

  • Migration creates a domain in the new configuration called PassThroughToGlobalSecurity if it does not already exist.
  • Migration adds a server-level mapping to the PassThroughToGlobalSecurity domain for all non-clustered servers in the old node's configuration.
    • Servers on the node being used migrated that are part of a cluster do not receive entries in the PassThroughToGlobalSecurity domain because this was addressed through a cluster mapping during deployment-manager migration.

      If we have removed that mapping, migration maintains that behavior.

    • Administrative servers (node agents) are not added to the PassThroughToGlobalSecurity domain.

See "Security domains in a mixed-version environment" section of Multiple security domains.

The process for disabling credential prompting has changed.

To disable credential prompting in v9.0, configure the ipc.client.props to disable credential prompting before migrating from v6.1 to v9.0.

During migration, some of the application metadata might be reset to the default and cause the application to function differently from what you expect.

If we installed an application in our old environment with Use Metadata From Binaries set to true and during that installation or a future update of the application we made a change to the application's metadata (such as JNDI resource references or database entries for example), the change might be lost when we migrate.

When Use Metadata From Binaries is set to true, the administrative code only updates the metadata in the binary EAR file. This option is not supported in a mixed cell; therefore, it is automatically turned to false as part of migration. When this happens, the expanded metadata in the configuration directories take precedence over the values in the binary EAR file. This causes the values from the original EAR file installation to take precedence over any updates that we might have made.

Perform one of the following actions to resolve this issue:

• Before migrating, update the applications in the old environment and set Use Metadata From Binaries to false. Ensure that the applications are functioning correctly with this new setting, and then run the migration.

• After migrating, update the applications and correct the metadata as required to allow the applications to function appropriately.

After we use the migration tools to migrate to WAS v9.0, we might need to perform some actions that are not done automatically by the migration tools.

• Examine any LTPA security settings that we might have used in WAS v7.0 or later, and verify that v9.0 security is set appropriately.

• Check the WASPostUpgrade.log file in the logs directory for details about any JSP objects that the migration tools did not migrate.

  If v9.0 does not support a level for which JSP objects are configured, the migration tools recognize the objects in the output and log them.

• Review JVM settings to verify that we are using a heap size of at least 50 for improved startup performance.

  If we have used a smaller heap size before, we can use the default heap size of 50.

• Verify the results of the automatic Apache Derby database migration, and manually migrate any Apache Derby databases that are not automatically migrated by the tools.

Related:

Migration tools

Migration Toolkit on WASdev.

Core group migration considerations

Multiple security domains

LTPA

Create application servers

Deprecated, stabilized, superseded, and removed features

Java virtual machine settings

Manually migrate Apache Derby databases