Migrating product configurations

Use the WebSphere® Application Server Version 9.0 migration tools to migrate your product configurations. These migration tools support migration from Version 7.0 or later.

Before you begin

Supported configurations:

This topic is about profile configuration migration. To migrate your applications to the latest version, use the WebSphere Application Server Migration Toolkit.

Read Overview of migration, coexistence, and interoperability and Migration considerations. For resources to help you plan and perform your migration, visit Knowledge Collection: Migration planning for WebSphere Application Server.

The following configuration upgrades of WebSphere Application Server versions and offerings are directly supported.
Table 1. Directly Supported Configuration Upgrades .

WebSphere Application Server Version 9.0 supports the migration of a subset of programming model extensions (PMEs) from WebSphere Business Integration Server Foundation.

You can migrate a WebSphere Application Server Network Deployment federated application server to a standalone server, however, after you migrate it, it becomes a federated server.
Migration Source (Version 7.0 or later) WebSphere Application Server Version 9.0, with Stand-alone and Custom Profiles as the target
WebSphere Application Server (base) stand-alone application server Supported
WebSphere Application Server Network Deployment stand-alone application server Supported
WebSphere Application Server Network Deployment federated application server Not supported
WebSphere Application Server Network Deployment deployment manager Not supported 
WebSphere Application Server Client Not supported 
Table 2. Directly Supported Configuration Upgrades .

WebSphere Application Server Version 9.0 supports the migration of a subset of programming model extensions (PMEs) from WebSphere Business Integration Server Foundation.

You can migrate a WebSphere Application Server Network Deployment federated application server to a standalone server, however, after you migrate it, it becomes a federated server.
Migration Source (Version 7.0 or later) WebSphere Application Server Version 9.0, with the deployment-manager management profile as the target
WebSphere Application Server (base) stand-alone application server Not supported
WebSphere Application Server Network Deployment stand-alone application server Not supported
WebSphere Application Server Network Deployment federated application server Not supported
WebSphere Application Server Network Deployment deployment manager Supported
WebSphere Application Server Client Not supported

You can migrate your product configurations using the WebSphere Application Server Version 9.0 Migration wizard or the command-line migration tools.

Before using the migration tools, consult the IBM WebSphere Application Server supported hardware, software, and APIs website to understand what fixes you must apply to earlier versions. Applying fixes to an earlier version might also apply fixes to files that have a role in the migration. Apply any fixes to ensure the most effective migration of configurations and applications.

Best practice: The deployment manager maintains the master configuration data for all of the nodes that it manages. This configuration data is updated through the configuration manager. When the configuration manager detects that the updates to the configuration data were not made against the latest saved copy, it rejects the updates and creates an exception. To avoid this situation, follow these best practices:
  • Migrate each node independently. For example, let the first node complete the migration process before starting the process for the second node, and so on.
  • Ensure that the administrative console for the deployment manager is not running when the migration process is in progress.

If you need to migrate federated nodes concurrently, use the following steps to minimize the potential failures:

Procedure

  1. Run the backupConfig command for the deployment manager and each federated node before you begin.
    For more information, see the documentation about the backupConfig command.
  2. Stop the nodeagent process before you migrate the nodes.
  3. Stagger the start of the migration process for each node by 3 to 5 minutes.
  4. Run the restoreConfig command on that node and rerun the migration process if a failure occurs.
    For more information, see the documentation about the restoreConfig command.