Migrating product configurations

Use the WebSphere® Application Server Version 8.0 migration tools to migrate your product configurations. These migration tools support migration from Version 6.x or 7.x.

Before you begin

Supported configurations 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 Application Migration Toolkit.

sptcfg

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.
Table 1. Profiles that can be migrated from Version 6.x or Version 7.x to Version 8.0. The table lists the supported profiles that can be migrated to WebSphere Application Server Version 8.0.
Migration Source Migration to WebSphere Application Server for z/OS® Version 8.0 Target supported?
Version 6.x Version 7.x
Stand-alone application server profile Supported Supported 
Deployment Manager profile Supported  Supported 
Managed (custom) application server profile Supported Supported
Administrative agent Not supported  Supported
Job Manager Not supported  Supported
* WebSphere Application Server for z/OS Version 8.0 supports the migration of a subset of programming model extensions (PMEs) from WebSphere Business Integration Server Foundation.

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 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 reject the updates and creates an exception. To avoid this situation, following 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:
  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. Stagger the start of the migration process for each node by 3 to 5 minutes.
  3. 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.
bprac



In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic Task topic    

Terms of Use | Feedback

Last updatedLast updated: Sep 20, 2011 12:50:17 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-nd-zos&topic=tmig_admin
File name: tmig_admin.html