Migrating product configurations

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

Before you begin

Supported configurations:

This topic is about configuration migration, such as migrating deployment managers and federated nodes in a network deployment environment. The Application Migration Toolkit for WebSphere Application Server provides support for migrating applications from previous versions of WebSphere Application Server to the latest product version. For information about migrating applications, read more about the Migration Toolkit.

Read Overview of migration, coexistence, and interoperability and Premigration 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.
[z/OS]
Table 1. Profiles that can be migrated from Version 6.1 or later to Version 8.5
Migration Source Migration to WebSphere Application Server for z/OS® Version 8.5 Target supported?
Stand-alone application server profile Supported
Deployment Manager profile Supported 
Managed (custom) application server profile Supported
Administrative agent Not supported 
Job Manager Not supported 
[z/OS]
Table 2. Profiles that can be migrated from Version 7.x or later to Version 8.5
Migration Source Migration to WebSphere Application Server for z/OS Version 8.5 Target supported?
Stand-alone application server profile Supported 
Deployment Manager profile Supported 
Managed (custom) application server profile Supported
Administrative agent Supported
Job Manager Supported

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: 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: restoreConfig command