WAS v8.0 > Migration and coexistence > Distributed operating systems > Scenario 1: Migrating a cell using the command line tools > 12. Migrate nodes


Migrate a v6.x or 7.x federated node


Overview

Scenarios involving the migration of WAS v6.0.0.x and 6.0.1.x federated nodes directly to v8.0 are not supported. Upgrade all v6.0.0.x and 6.0.1.x federated nodes to at least v6.0.2 before attempting to migrate them to v8.0.


Procedure

  1. Perform a typical or custom WAS v8.0 installation

  2. Use the WAS v8.0 Profile Management tool or the manageprofiles command to create a application server or custom profile, but do not federate the node. The migration tools federate the v8.0 node during migration.

  3. Migrate the WAS v6.x or 7.x dmgr to v8.0

  4. Collect the following information:

    • Migration backup directory name

    • Installation root directory
    • Administrative user name for the current installation
    • Password for the administrative user name of the current installation
    • Source profile name
    • Target profile name
    • Applications to be migrated
    • Port value assignments

  5. Ensure that the v8.0 dmgr is up and running.

    We can migrate a v6.x or 7.x node whether the node is running or stopped. The migration tools can retrieve all the configuration data either way. We must stop the v6.x or 7.x node before you can start the v8.0 node that you are installing.

  6. Run backupConfig to back up the v8.0 dmgr configuration.

  7. Run backupConfig to back up the v6.x or 7.x federated node configuration.

  8. Determine the node name of the v6.x or 7.x federated node. Use the same name for the node that was used for the v6.x or 7.x federated node name.

  9. If you make any cell-level changes to the new v8.0 node before migration, such as changes to virtual-host information, these changes will be lost during migration. Therefore, you should wait until after the node has been migrated before making any such changes. Otherwise, you will have to manually remake all of the changes to the new cell after migration using the administrative console running on the dmgr. This tip is reflected in message MIGR0444W.

  10. Use the Migration tools or wizard to migrate the WAS v6.x or 7.x federated node to v8.0.

    The Migration wizard copies the configuration and applications from the v6.x or 7.x federated node to the v8.0 configuration. After migrating all of the data, the Migration wizard federates the v8.0 node into the dmgr cell.

  11. Stop and restart each of the application servers on the migrated node.

    For migration to be successful, use the same node names and cell names for each node that you migrate from v6.x or 7.x to v8.0.

  12. If necessary, troubleshoot migration.

  13. If necessary, roll back the federated node that you just migrated.

  14. After migrating a WAS v6.x or 7.x dmgr to a v8.0 dmgr, the v8.0 dmgr runs in compatibility mode by default. The v8.0 dmgr can manage v6.x or 7.x, and v8.0 release nodes in this mode. The federated nodes of the v6.x dmgr will as v6.x federated nodes in the v8.0 WAS ND cell. Over time, migrate each WAS v6.x or 7.x federated node in the v8.0 cell to v8.0.

    After migrating all v6.x or 7.x federated nodes, to change the dmgr to support only v8.0....


What to do next

Occasionally (after rebooting an application server machine for example), restart the nodeagent server on the application server node by running the startNode command from...

To keep the application server nodes running without having to access the bin directory of each one, use the operating system to monitor and restart the node agent process on each application server node. (We can also set up the dmgr server as a managed process on the dmgr node.) For more information, read the "Automatically restarting server processes" article in the information center.

Add a node automatically issues the startNode command for the node.

When a dmgr is migrated, the applications in the cell are reinstalled. Even though the name is unchanged, the application is different from the version that was deployed on the previous release. When the federated nodes synchronize with the migrated dmgr, therefore, they detect the new application and download it. After the application has been downloaded (synchronized), the node agent uses the new application rather than the old application. If the application is running on any active servers, the application will appear to restart as the old application is stopped and uninstalled and the new application is installed and started.

If you want to uninstall the old product, and you have migrated v6.x or 7.x managed nodes, either shut down the new migrated dmgr before uninstalling, or include the parameter...

...on the uninstall command. Either of these options prevents the migrated profiles from being deleted when you uninstall the old version of the product.

+

Search Tips   |   Advanced Search