You can migrate administrative configurations with the Installation wizard or with the migration tools, as this task describes. If you decide to use the migration tools, do not select the Migration check box on the Migration panel of the Installation wizard.
Before you begin
If you use an earlier version of WebSphere Application Server, the system administrator might have fine-tuned various application and server settings for your environment. It is important to have a strategy for migrating these settings with maximum efficiency and minimal loss.
You can perform incremental migration of Version 3.5.x or Version 4.0.x nodes by calling the migration tools multiple times, each time specifying a different configuration file. Various reasons exist for having multiple configuration files. Whatever the reason, migrating one configuration file at a time lets you test applications incrementally before continuing to the next configuration file.
Before using the migration tools,
consult the Version 5.0.x Release Notes document 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
possible.
Why and when to perform this task
IBM
provides a set of migration tools for migrating administrative configurations
from Version 3.5.x, or Version 4.x to the Version 5.0.x base product, Network
Deployment product, or Enterprise product.
The overall migration process when you issue the commands to use the migration tools instead of letting the installation program issue the commands is:
WASPostUpgrade
uses the backupConfig command to save the existing Version 5.0.x configuration
before performing migration. The results are stored in the install_root/temp directory.
You can use the restoreConfig command to restore the backup, if required.
Steps for this task
Start
the Version 5.0.x deployment manager. During migration, the Version 5.0.x
deployment manager must be running for the migration tools to:
Operating platform | Tip in Platform-specific tips for installing and migrating |
---|---|
All platforms | Recovering from configuration errors when the deployment manager was not running during migration. |
Rule | Description |
---|---|
A federated node has no control over its feature configuration. | The deployment manager owns the configuration of all federated nodes, including the configuration of features on those nodes. When migrating a federated node, the configuration on the base node is owned by the deployment manager and cannot be changed. |
Unfederate a node to let the node own its configuration, if you must add features to the node. | It is always true that you must unfederate a node before adding features. You then add the node back to the cell to cause the deployment manager to add the changed configuration of the base node. |
Install the Version 5.1 node with features that make it appear to be a clone of the node that you are migrating. | When migrating, select the same features for the new node that are in the existing node. Adding or changing features can cause configuration problems in a federated node. The most trouble-free path is to select the same features. |
It is possible to migrate from one machine to another. | One of the tasks introduced in this topic describes how to migrate a federated node to Version 5.1 on a different machine. |
If you are migrating a federated node, select the same type of installation that you chose when you installed the earlier release. If you selected a full installation type, select a full installation type now. If you selected a custom installation type, select a custom installation type now and select the same features that you did for the Version 5.0.x release. Federated nodes have configurations that are controlled by the deployment manager that controls the cell.
Migrating
a federated node installs the same features for the node that are in the configuration
for the Version 5.0.x node.
Select one of the following migration scenarios for information about how to migrate configuration data to base WebSphere Application Server nodes:
startNode.shOccasionally, for example after rebooting an Application Server machine, you must restart the node agent server on the Application Server node, by running the startNode command. To keep your Application Server nodes running without accessing the bin directory of each one, use the operating system to monitor and restart the nodeagent process on each Application Server node. You can also set up the dmgr server as a managed process on the deployment manager node.
See Automatically restarting WebSphere processes for more information.
Adding a node automatically issues the startNode command for the node.
Results
You can use the migration tools to migrate from one version of WebSphere Application Server to another.What to do next
Return to Migrating and coexisting to continue.