Use the migration tools to migrate WebSphere Application Server Version 5.x managed nodes to Version 6.0.x managed nodes.
Before you begin
Migrating a Version 5.x managed node to a Version 6.0.x managed node requires that you first migrate the Version 5.x deployment manager node to a Version 6.0.x deployment manager node. Migrating Network Deployment Version 5.x to Version 6.0.x is described in Migrating from Network Deployment Version 5.x to a Version 6.0.x deployment manager.
Before starting the migration of a managed node from Version 5.x to Version 6.0.x, you must create a Version 6.0.x profile for either a stand-alone application server or a managed node. If you create a Version 6.0.x managed node profile, do not federate the node before migration. The migration tools federate the Version 6.0.x node during migration.
The migration procedure is the same for either type of Version 6.0.x profile, but he end result can vary slightly. Each stand-alone application server has a server1 application server process. A Version 5.x managed node might not have a server1 process. This article describes migrating to a Version 6.0.x managed node that has not been federated.
Why and when to perform this task
After migrating a Version 5.x deployment manager to a Version 6.0.x deployment manager, the Version 6.0.x deployment manager runs in compatibility mode by default, where it can manage both Version 5.x and Version 6.0.x nodes. The managed nodes of the Version 5.x deployment manager are now running as Version 5.x managed nodes in the Version 6.0.x deployment manager.
Over time, migrate each Version 5.x managed node in the Version 6.0.x cell to a Version 6.0.x managed node. After migrating all Version 5.x managed nodes, use the convertScriptCompatibility script to change the deployment manager from a node that supports backward compatibility of Version 5.x administration scripts to a node that supports only Version 6.0.x.
Steps for this task
See WASPreUpgrade command for a description of the currentWebSphereDirectory parameter.
Specifying “true” causes any ports of matching VirtualHosts to first be removed from the new configuration before adding the new values.
Specifying “false” for this parameter will just add new port values.
See WASPostUpgrade command for a description of the replacePorts parameter.
See WASPreUpgrade command for a description of the backupDirectory parameter.
See WASPostUpgrade command for a description of the profileName parameter.
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 nodeagent process on each application server 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.