Before you begin
Read
Overview of migration, coexistence, and interoperability and
Premigration considerations.
Typically, you can use the WASPreUpgrade and
the WASPostUpgrade migration tools to upgrade from
Version 5.1.x or Version 6.x to Version 7.0 on the same machine. However,
some scenarios require that you migrate the Version 5.1.x or Version
6.x configuration on one machine to Version 7.0 on a different machine.
One of these scenarios is when you install new machines for your Version 7.0 environment but need to migrate your existing Version 5.1.x or
Version 6.x configuration from other machines.
If the node that you are migrating is part
of a WebSphere® Application Server, Network Deployment cell, migrate the 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 or Migrating to Version 7.0 deployment managers on remote machines before continuing this
procedure. The deployment manager must always be at the highest release
level within the cell.
To ensure that your operating system
is supported by WebSphere Application Server Version 7.0,
visit the following site for the most current list of supported hardware
and software: WebSphere Application Server system requirements.
If you find that your operating
system is not supported for migration to Version 7.0, read Migrating standalone application servers from unsupported operating systems.
The Version 7.0 WASPreUpgrade command
saves the existing Version 5.1.x or Version 6.x configuration into
a migration-specific backup directory. The Version 7.0 WASPostUpgrade command
uses this directory to add the old configuration settings to the new
Version 7.0 environment.
Tip: Before migrating a WebSphere Application Server Version 5.1.x
or Version 6.x federated node on a remote machine, use the backupConfig command
or your own preferred backup utility to back up your existing configuration
if you want to be able to restore it to its previous state after migration.
Read the "backupConfig command" article in the information center
for more information. Make sure that you note the exact name and location
of this backed-up configuration.
For help in troubleshooting
problems when migrating, read Troubleshooting migration.
- Migrate the Version 5.1.x or Version 6.x deployment manager
to Version 7.0.
Read Migrating to a Version 7.0 deployment manager or Migrating to Version 7.0 deployment managers on remote machines for
more information.
- Update any Web sever configurations and supporting software.
Read Migrating Web server configurations for
more information.
- Run the WASPreUpgrade on the federated
node on the WebSphere Application Server Version 5.1.x
or Version 6.x machine.
Perform one of the following
procedures:
Important: In either case, the old machine must support
the WebSphere Application Server Version 7.0
JVM.
Save the configuration in the migration_specific_backup directory
on the Version 5.1.x or Version 6.x machine.
./WASPreUpgrade.sh /filepath/migration_specific_backup /opt/WebSphere/AppServer -machineChange true
WASPreUpgrade C:\filepath\migration_specific_backup C:\Program Files\WebSphere\AppServer -machineChange true
The WASPreUpgrade command provides
status to the screen and to log files in the migration_specific_backup directory.
ASCII log file names start with the text WASPreUpgrade and
include a date and timestamp.
- Install WebSphere Application Server Version 7.0 on the Version 7.0 machine.
- Use the Profile Management Tool or the manageprofiles command
to create a WebSphere Application Server Version 7.0
profile on the Version 7.0 machine.
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.
Read the "Creating profiles using
the graphical user interface" article or the "manageprofiles command"
article in the information center for more information.
- Copy the migration_specific_backup directory
from the WebSphere Application Server Version 5.1.x
or Version 6.x machine to the Version 7.0 machine.
Use
the ftp command, shared storage, or some other
mechanism to copy the directory to the new machine.
- Optional: Shut down the federated nodes and
servers on the Version 5.1.x or Version 6.x machine.
- Add the WebSphere Application Server
Version 5.1.x or Version 6.x configuration to the Version 7.0 configuration.
Read WASPostUpgrade command for
more information.
Use the WASPostUpgrade command
in the app_server_root/bin directory
of the Version 7.0 installation to add the Version 5.1.x or Version
6.x configuration to the Version 7.0 configuration.
./WASPostUpgrade.sh /filepath/migration_specific_backup
WASPostUpgrade C:\filepath\migration_specific_backup
The WASPostUpgrade tool records information
specific to each enterprise bean it deploys in the migration_specific_backup/WASPostUpgrade.log file.
- Modify the configuration using the WebSphere Application Server Version 7.0 administrative console.
- Change user IDs and passwords to match security requirements.
You might have to change user IDs and passwords if they are
not identical to those in use on the Version 5.1.x or Version 6.x
machine.
- Change other machine-specific information.
The
configuration might refer to other software products or configurations
that do not exist on the new machine. For example, the old machine
might have a database. Modify the data source to point to the database
on the old machine.
- Manually disable the federated node on the Version 5.1.x
or Version 6.x machine.
When you run the WASPostUpgrade command,
the old node agent is stopped on the original machine; but it is still
necessary to manually disable the federated node. The simplest way
to do this is to rename the serverindex.xml file
for the federated node on the old profile to something other than
that name. Migration on the same machine renames the file to serverindex.xml_disabled.
This is required to ensure that the old node agent is not
started. Having the old release's node agent communicating with the
migrated deployment manager after the federated node has been migrated
is not supported.
- Start the node agent by running the startNode command
from the profile_root/bin directory.
- Manually synchronize the node with the migrated deployment
manager.
If you fail to do so, the node will not be
able to communicate with the deployment manager and migration will
not be able to upgrade the federated node.