+

Search Tips   |   Advanced Search

 

Migrate to a V6.1 managed appserver

 

Use the migration tools to migrate WAS V5.x or 6.0.x managed nodes to V6.1 managed nodes.

See Overview of migration, coexistence, and interoperability and Premigration considerations.

Migrating a WAS V5.x or 6.0.x managed node to a Version 6.1 managed node requires that you first migrate the V5.x or 6.0.x deployment manager to a V6.1 deployment manager. Migrating Network Deployment V5.x or 6.0.x to V6.1 is described in Migrating to a V6.1 deployment manager .

Before starting the migration of a managed node from WAS V5.x or 6.0.x to V6.1, you can create either a V6.1 standalone appserver profile or a custom profile as a target. If you create a V6.1 custom node, do not federate the node before migration. The migration tools federate the Version 6.1 node during migration.

Scenarios involving the migration of WAS V6.0.0.x and 6.0.1.x managed nodes directly to V6.1 are not supported. Upgrade all Version 6.0.0.x and 6.0.1.x managed nodes to at least V6.0.2 before attempting to migrate them to V6.1.

When migrating a WAS V5.x or 6.0.x managed node, perform the following actions if you want to be able to roll it back to its previous state after migration:

  1. Back up your existing configuration using the backupConfig command or your own preferred backup utility.

    • Run the backupConfig command or your own preferred utility to back up the V6.1 deployment manager configuration.

      Verify you note the exact name and location of this backed-up configuration.

      See backupConfig command.

    • Run the backupConfig command or your own preferred utility to back up the V5.x or 6.0.x managed node configuration.

      Verify you note the exact name and location of this backed-up configuration.

      See backupConfig command.

  2. Migrate the managed node.

If necessary, you can now roll back the managed node that you just migrated. See Rolling back a managed node.

 

Overview

After migrating a WAS V5.x or 6.0.x deployment manager to a V6.1 deployment manager, the Version 6.1 deployment manager runs in compatibility mode by default, where it can manage V5.x, V6.0.x, and V6.1 release nodes. The managed nodes of the V5.x or 6.0.x deployment manager are now running as Version 5.x or 6.0.x managed nodes in the V6.1 deployment manager. See Coexistence support for information on restrictions on using mixed-release cells.

V6 cell with mixed version nodes

Over time, migrate each WAS Version 5.x or 6.0.x managed node in the V6.1 cell to a V6.1 managed node. After migrating all V5.x or 6.0.x managed nodes, use the convertScriptCompatibility script to change the deployment manager from a node that supports backward compatibility of V5.x or 6.0.x administration scripts to a node that supports only V6.1. See convertScriptCompatibility command.

For help in troubleshooting problems when migrating, see Troubleshooting migration.

 

Procedure

  1. Perform a typical or custom WebSphere Application Server V6.1 installation as described in Installing the product and additional software.

  2. Migrate the WAS V5.x or 6.0.x deployment manager to V6.1 as described in Migrating to a V6.1 deployment manager .

  3. Collect the following information before you continue this procedure. The Migration wizard will prompt you for the following information during the migration:

     

  4. Optional: Use the WAS Version 6.1 Profile Management tool to create a managed node, but do not federate the node.

    See Creating profiles through the graphical user interface.

    Use the same name for the managed node that was used for the V5.x or 6.0.x managed node name.

    If you make any cell-level changes to the new V6.1 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, such as any changes to the virtual-host and host-alias information, to the new cell after migration using the console running on the deployment manager. This tip is reflected in message MIGR0444W.

  5. Ensure that the V6.1 deployment manager is up and running.

    You can migrate a V5.x or 6.0.x node whether the node is running or stopped. The migration tools can retrieve all the configuration data either way. You must stop the V5.x or 6.0.x node before you can start the V6.1 node that you are installing, however, so it makes sense to stop it now.

  6. Use the Migration wizard to migrate the WAS V5.x or 6.0.x managed node to a V6.1 managed node profile as described in Migrating to a V6.1 appserver using the Migration wizard. The Migration wizard copies the configuration and applications from the V5.x or 6.0.x managed node to the V6.1 managed node. After migrating all of the data, the Migration wizard federates the V6.1 managed node into the deployment manager cell.

    When migrating managed nodes from Versions 5.0 through 5.1.0 to V6.1, there is a custom property of which you should be aware: com.ibm.websphere.ObjectIDVersionCompatibility. It might be possible to gain performance benefits after the entire cell is migrated to V6.1. See Object Request Broker custom properties for complete details.

  7. Migrate as many WAS V5.x or 6.0.x managed nodes as you intend to migrate by using the following procedure.

    1. Determine the node name of the V5.x or 6.0.x managed node.

       

    2. Optional: Use the Profile Management tool to create a V6.1 managed node, but do not federate the node.

    3. Use the Migration wizard to migrate the V5.x or 6.0.x managed node to a V6.1 managed node.

    4. Stop and restart each of the appservers on the migrated node.

    For migration to be successful, use the same node names and cell names for each node that you migrate from V5.x or 6.0.x to V6.1.

  8. If you chose the compatibility option (which is the default), and if all of your nodes are completely migrated to WAS V6.1, run the convertScriptCompatibility script to remove backward compatibility from the WAS Version 6.1 deployment manager. Issue the convertScriptCompatibility command from the bin directory.

    See convertScriptCompatibility command.

 

What to do next

Occasionally (after rebooting an appserver machine for example), restart the nodeagent server on the appserver node by running the startNode command from the profile_name/bin directory. To keep your appserver nodes running without having to access the bin directory of each one, use the operating system to monitor and restart the nodeagent process on each appserver node. (You can also set up the dmgr server as a managed process on the deployment manager node.) For more information, see Automatically restarting server processes.

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



Migrating product configurations
Use the Migration wizard to migrate product configurations