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:
- Back up your existing configuration using the backupConfig command
or your own preferred backup utility.
- 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.

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
- Perform a typical or custom WebSphere Application Server
Version 6.1 installation.
- 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.
- Collect the following information before you continue this
procedure. The Migration wizard will prompt you for the following
information during the migration:
- 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.
- 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.
- 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.
- Determine the node name of the Version 5.x or 6.0.x
managed node.
- Optional: Use the Profile Management tool
to create a Version 6.1 managed node, but do not federate the node.
- 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: 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
- 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.
- 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.
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.