[AIX HP-UX Linux Solaris Windows]

Migrating to a Version 6.1 managed application server

Use the migration tools to migrate WebSphere Application Server Version 5.x or 6.0.x managed nodes to Version 6.1 managed nodes.

Before you begin

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

Migrating a WebSphere Application Server Version 5.x or 6.0.x managed node to a Version 6.1 managed node requires that you first migrate the Version 5.x or 6.0.x deployment manager to a Version 6.1 deployment manager. Migrating Network Deployment Version 5.x or 6.0.x to Version 6.1 is described in Migrating to a Version 6.1 deployment manager.

Before starting the migration of a managed node from WebSphere Application Server Version 5.x or 6.0.x to Version 6.1, you can create either a Version 6.1 standalone application server profile or a custom profile as a target. If you create a Version 6.1 custom node, do not federate the node before migration. The migration tools federate the Version 6.1 node during migration.

Restriction: Scenarios involving the migration of WebSphere Application Server Version 6.0.0.x and 6.0.1.x managed nodes directly to Version 6.1 are not supported. Upgrade all Version 6.0.0.x and 6.0.1.x managed nodes to at least Version 6.0.2 before attempting to migrate them to Version 6.1.
Tip: When migrating a WebSphere Application Server Version 5.x or 6.0.x managed node, you must 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 Version 6.1 deployment manager configuration.
      Important: Make sure that you note the exact name and location of this backed-up configuration.
    • Run the backupConfig command or your own preferred utility to back up the Version 5.x or 6.0.x managed node configuration.
      Important: Make sure that you note the exact name and location of this backed-up configuration.
  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.

About this task

After migrating a WebSphere Application Server Version 5.x or 6.0.x deployment manager to a Version 6.1 deployment manager, the Version 6.1 deployment manager runs in compatibility mode by default, where it can manage Version 5.x, Version 6.0.x, and Version 6.1 release nodes. The managed nodes of the Version 5.x or 6.0.x deployment manager are now running as Version 5.x or 6.0.x managed nodes in the Version 6.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 WebSphere Application Server Version 5.x or 6.0.x managed node in the Version 6.1 cell to a Version 6.1 managed node. After migrating all Version 5.x or 6.0.x managed nodes, use the convertScriptCompatibility script to change the deployment manager from a node that supports backward compatibility of Version 5.x or 6.0.x administration scripts to a node that supports only Version 6.1. See convertScriptCompatibility command.

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

Procedure

  1. Perform a typical or custom WebSphere Application Server Version 6.1 installation.
  2. Migrate the WebSphere Application Server Version 5.x or 6.0.x deployment manager to Version 6.1 as described in Migrating to a Version 6.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 WebSphere Application Server Version 6.1 Profile Management tool to create a managed node, but do not federate the node.

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

    Tip: If you make any cell-level changes to the new Version 6.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 administrative console running on the deployment manager. This tip is reflected in message MIGR0444W.
  5. Ensure that the Version 6.1 deployment manager is up and running.
    Note: You can migrate a Version 5.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 Version 5.x or 6.0.x node before you can start the Version 6.1 node that you are installing, however, so it makes sense to stop it now.
  6. Migrate as many WebSphere Application Server Version 5.x or 6.0.x managed nodes as you intend to migrate by using the following procedure.
    1. Determine the node name of the Version 5.x or 6.0.x managed node.
    2. Optional: Use the Profile Management tool to create a Version 6.1 managed node, but do not federate the node.
    3. Use the Migration wizard to migrate the Version 5.x or 6.0.x managed node to a Version 6.1 managed node profile as described in Migrating to a Version 6.1 application server using the Migration wizard.
      The Migration wizard copies the configuration and applications from the Version 5.x or 6.0.x managed node to the Version 6.1 managed node. After migrating all of the data, the Migration wizard federates the Version 6.1 managed node into the deployment manager cell.
      Note: When migrating managed nodes from Versions 5.0 through 5.1.0 to Version 6.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 Version 6.1.
      Avoid trouble Avoid trouble: If you migrate any Version 5.x or 6.0.x managed nodes, you must either shut down the new migrated deployment manager before uninstalling the old product, or include the removeProfilesOnUninstall="false" 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. gotcha
    4. Stop and restart each of the application servers on the migrated node.
    Note: For migration to be successful, you must use the same node names and cell names for each node that you migrate from Version 5.x or 6.0.x to Version 6.1.
  7. If you chose the compatibility option (which is the default), and if all of your nodes are completely migrated to WebSphere Application Server Version 6.1, run the convertScriptCompatibility script to remove backward compatibility from the WebSphere Application Server Version 6.1 deployment manager.
    Issue the convertScriptCompatibility command from the bin directory.
    • [AIX] [HP-UX] [Linux] [Solaris] app_server_root/bin/convertScriptCompatibility.sh
    • [Windows] app_server_root\bin\convertScriptCompatibility.bat

    See convertScriptCompatibility command.

What to do next

Occasionally (after rebooting an application server machine for example), you must restart the nodeagent server on the application server node by running the startNode command from the profile_name/bin directory. To keep your 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. (You can also set up the dmgr server as a managed process on the deployment manager node.)

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

Note: When a deployment manager 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 deployment manager, 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.



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 and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 1:23:07 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-dist&topic=tmig_to61mas
File name: tmig_to61mas.html