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.
- Use the Migration wizard to migrate the WebSphere Application Server
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.
- 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.
- 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.