Use the migration tools to migrate WebSphere® Application Server Version 5.1.x
or Version 6.x federated nodes to Version 7.0.
Before you begin
Read Overview of migration, coexistence, and interoperability and Premigration considerations. For resources to help you plan and perform
your migration, visit Knowledge Collection: Migration planning for WebSphere Application Server.
Migrating
a WebSphere Application Server Version
5.1.x or Version 6.x federated node requires that you first migrate
the Version 5.1.x or Version 6.x deployment manager to a Version 7.0 deployment manager.
This procedure is described in Migrating to a Version 7.0 deployment manager.
Before
starting the migration of a federated node from WebSphere Application Server Version 5.1.x
or Version 6.x, you can create either a Version 7.0 standalone application
server profile or a custom profile as a target. If you create a Version 7.0 custom node, do not
federate the node before migration. The migration tools federate the Version 7.0 node during migration.
Restriction: Scenarios involving the migration of WebSphere Application Server Version 6.0.0.x
and 6.0.1.x federated nodes directly to Version 7.0 are not supported.
Upgrade all Version 6.0.0.x and 6.0.1.x federated nodes to at least
Version 6.0.2 before attempting to migrate them to Version 7.0.
Tip: When migrating a
WebSphere Application Server Version 5.1.x
or Version 6.x federated 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.
- Run the backupConfig command or your own preferred
utility to back up the Version 7.0 deployment
manager configuration.
Important: Make sure that you note
the exact name and location of this backed-up configuration.
Read
the "backupConfig command" article in the information center for more
information.
- Run the backupConfig command or your own preferred
utility to back up the Version 5.1.x or Version 6.x federated node
configuration.
Important: Make sure that you note the exact
name and location of this backed-up configuration.
Read the
"backupConfig command" article in the information center for more
information.
- Migrate the federated node.
- If necessary, you can now roll back the federated node that you
just migrated.
For more information, read Rolling back a federated
node.
Decide whether you want to migrate from WebSphere Application Server Version 5.1.x
or Version 6.x to Version 7.0 using
the Migration wizard or using the command-line migration tools.
About this task
After migrating a WebSphere Application Server Version 5.1.x
or Version 6.x deployment manager to a Version 7.0 deployment manager,
the Version 7.0 deployment
manager runs in compatibility mode by default. The Version 7.0 deployment manager
can manage Version 5.1.x, Version 6.x, and Version 7.0 release nodes in
this mode. The federated nodes of the Version 5.1.x or Version 6.x
deployment manager are now running as Version 5.1.x or Version 6.x
federated nodes in the Version 7.0 WebSphere Application Server, Network Deployment cell. Read Coexistence support for information on restrictions on
using mixed-release cells.
Over time, migrate each WebSphere Application Server Version 5.1.x
or Version 6.x federated node in the Version 7.0 cell to Version 7.0. After migrating
all Version 5.1.x or Version 6.x federated nodes, use the convertScriptCompatibility script
to change the deployment manager from a node that supports backward
compatibility of Version 5.1.x or Version 6.x administration scripts
to a node that supports only Version 7.0. Read convertScriptCompatibility command for more information.
For
help, read Troubleshooting migration.
Procedure
- Perform a typical or custom WebSphere Application Server Version 7.0 installation as described
in the "Installing the product and additional software" article in
the information center.
- Migrate the WebSphere Application Server Version
5.1.x or Version 6.x deployment manager to Version 7.0 as described in Migrating to a Version 7.0 deployment manager.
- Collect the following information (the Migration wizard
prompts you for the information during the migration):
- Migration backup directory name
- Installation root directory
- Administrative user name for the current installation
- Password for the administrative user name of the current installation
- Source profile name
- Target profile name
- Applications to be migrated
- Port value assignments
Read WASPreUpgrade command and WASPostUpgrade command for descriptions
of the parameters related to this required information as well as
optional parameters.
- Ensure that the Version 7.0 deployment
manager is up and running.
Note: You can migrate a Version
5.1.x or Version 6.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.1.x or Version 6.x node before you
can start the Version 7.0 node
that you are installing, however, so it makes sense to stop it now.
- Migrate as many WebSphere Application Server Version 5.1.x
or Version 6.x federated nodes as you intend to migrate by using the
following procedure.
- Determine the node name of the Version 5.1.x or Version
6.x federated node.
- Optional: Use the WebSphere Application Server Version 7.0 Profile Management
tool or the manageprofiles command to create a
application server or custom profile, but do not federate the node.
Restriction: You cannot use the Profile Management
Tool to create profiles for WebSphere Application Server installations
on 64-bit architectures except on the Linux for zSeries platform.
However, you can use the Profile Management Tool on other 64–bit architectures
if you use a WebSphere Application Server 32–bit
installation.
Supported configurations: You cannot use the
Profile Management Tool to create profiles for WebSphere Application
Server installations on 64-bit architectures
except on the
Linux for zSeries platform. However, you can use the Profile Management
Tool on other 64–bit architectures if you use a WebSphere Application
Server 32–bit installation.
sptcfg
Read the
"Creating profiles using the graphical user interface" article or
the "manageprofiles command" article in the information center for
more information.
Use the same name for the node that was used
for the Version 5.1.x or Version 6.x federated node name.
Tip: If you make any cell-level changes to the new Version 7.0 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 to the new cell
after migration using the administrative console running on the deployment
manager. This tip is reflected in message MIGR0444W.
- Perform one of the following procedures to migrate the
Version 5.1.x or Version 6.x federated node to Version 7.0.
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
- Use the Migration wizard to migrate the WebSphere Application Server Version 5.1.x
or Version 6.x federated node to Version 7.0 as described in Migrating
a Version 5.1.x or Version 6.x federated node using the Migration
wizard.
The Migration wizard, which is the graphical interface to
the Version 7.0 command-line
migration tools (WASPreUpgrade and WASPostUpgrade), is the recommended
migration tool. For instructions and information on the Migration
wizard, read Migrating product configurations with the migration wizard.
The
Migration wizard copies the configuration and applications from the
Version 5.1.x or Version 6.x federated node to the Version 7.0 configuration. After
migrating all of the data, the Migration wizard federates the Version 7.0 node into the deployment
manager cell.
- Use the command-line tools to migrate the WebSphere Application Server Version 5.1.x
or Version 6.x federated node to Version 7.0.
Read WASPreUpgrade
command and WASPostUpgrade command for more information.
Note: When migrating federated nodes from Version 5.1.0 to Version 7.0, 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 7.0.
Read the "Object Request Broker custom properties" article in the
information center for complete details.
- 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.1.x or Version 6.x to Version 7.0.
- If you chose the compatibility option (which is the default)
and if all of your nodes are completely migrated to WebSphere Application Server Version 7.0, run the convertScriptCompatibility script
to remove backward compatibility from the WebSphere Application Server Version 7.0 deployment manager.
Issue the
convertScriptCompatibility command
from the
bin directory.
- app_server_root/bin/convertScriptCompatibility.sh
- app_server_root\bin\convertScriptCompatibility.bat
Read convertScriptCompatibility command for
more information.
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_root/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.) For more information, read the "Automatically
restarting server processes" article in the information center.
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.