Why and when to perform this task
To resolve problems encountered in migrating from
an older version of WebSphere Application Server, determine whether your problems
occur using the pre-upgrade tool or the post-upgrade tool.
Steps for this task (dependent on configuration)
- The following problems can occur when using
the pre-upgrade tool:
- A "Not found" or "no such file or directory" message is returned
from the WASPostUpgrade or WASPreUpgrade tool. This problem can
occur if you are trying to run the WASPostUpgrade tool or the WASPreUpgrade
tool from a directory other than install_dir\bin. Verify
that the WASPostUpgrade or WASPreUpgrade .bat or .sh files
reside in the install_dir\bin directory, and launch either
file from that location.
- The DB2 JDBC driver and DB2 JDBC driver (XA) cannot be found
in the drop down list of supported JDBC providers in the administrative console
The administrative console no longer displays deprecated JDBC provider
names. The new JDBC provider names used in the administrative console are
more descriptive and less confusing. The new providers will differ only by
name from the deprecated ones.
The deprecated names will continue to exist
in the jdbc-resource-provider-templates.xml file for
migration reasons (for example, for existing JACL scripts). However, you are
encouraged to use the new JDBC provider names in your JACL scripts.
- You receive message: MIGR0108E: The specified WebSphere
directory does not contain WebSphere version that can be upgraded.
Several possible reasons for this error exist:
- If WebSphere Application Server Version 4.0.x or 5.x is installed, you
might not have run the WASPreUpgrade tool from the bin directory
of the Version 6 installation root.
- Look for the following message to display when the WASPreUpgrade tool
runs: IBM WebSphere Application Server, Release 4.0. This message
indicates that you are running the WebSphere Application Server Release 4.0
migration utility, not the version 6 migration utility.
- Alter your environment path or change the current directory so that you
can launch the WebSphere Application Server Version 6 WASPreUpgrade program.
- An invalid directory might have been specified when launching the WASPostUpgrade
tool, or the WASPreUpgrade tool has not been run.
- MIGR0125E: The call to XMLConfig was not successful error
when trying to run WASPreUpgrade The WASPreUpgrade tool saves
selected files from WebSphere Application Server Version Version 4.x and Version
5.x bin directories. It also exports the existing application server
configuration from the repository.
If you are migrating from WebSphere
Application Server Version 4.0.x Advanced Edition, the WASPreUpgrade command
calls the XMLConfig command to export the existing application
server configuration from the repository. If errors occur during this part
of the WASPreUpgrade command, you might have to apply fixes
to the installation to successfully complete the export step. Contact IBM Support for the latest applicable fixes.
- The following problems can occur when using
the post-upgrade tool:
- A "Not found" or "no such file or directory" message is returned
from the WASPostUpgrade or WASPreUpgrade tool. This problem can
occur if you are trying to run the WASPostUpgrade tool or the WASPreUpgrade
tool from a directory other than install_dir\bin. Verify
that the WASPostUpgrade or WASPreUpgrade .bat or .sh files
reside in the install_dir\bin directory, and launch either
file from that location.
- You receive message: MIGR0102E: Invalid Command Line.
MIGR0105E: You must specify the primary node name. The
most likely cause of this error is that Version 4.0.x or 5.x of the WebSphere
Application Server is installed, and the WASPostUpgrade tool was not run from
the bin directory of the WebSphere Application Server Version 6 installation
root.
If the following messages appear when the WASPostUpgrade tool is run,
the Version 4.0 migration tool was run:
- IBM WebSphere Application Server, Release 4.0
MIGR0002I: java com.ibm.websphere.migration.postupgrade.WASPostUpgrade
<backupDirectoryName>
-adminNodeName <primary node name>
[-nameServiceHost <hostName> [ -nameServicePort <portNumber>]]
[-substitute <"key1=value1[;key2=value2;[...]]">]
In input xml file, the key(s) should appear as $key$ for substitution.")
[-import <xml data file>]
[-traceString <trace specification> [-traceFile <filename>]]}"
To correct this problem, run the WASPostUpgrade command
from the bin directory of the WebSphere Application Server Version
6 installation root.
- You receive message: MIGR0108E: The specified WebSphere
directory does not contain WebSphere version that can be upgraded.
Several possible reasons for this error exist:
- If WebSphere Application Server Version 4.0.x or 5.x is installed, you
might not have run the WASPreUpgrade tool from the bin directory
of the Version 6 installation root.
- Look for the following message to display when the WASPreUpgrade tool
runs: IBM WebSphere Application Server, Release 4.0. This message
indicates that you are running the WebSphere Application Server Release 4.0
migration utility, not the version 6 migration utility.
- Alter your environment path or change the current directory so that you
can launch the WebSphere Application Server Version 6 WASPreUpgrade program.
- An invalid directory might have been specified when launching the WASPostUpgrade
tool, or the WASPreUpgrade tool has not been run.
- You receive message: MIGR0116E: The backup directory
[migration_backup_directory] does not contain the required xml data file.
If Version 4.0.x of WebSphere Application Server is installed, you
might not have run the WASPostUpgrade tool from the
bin directory
of the Version 6 installation root.
- If the message IBM WebSphere Application Server, Release 4.0 displays
when launching the WASPostUpgrade program, then the wrong version of the program
is executing.
- Run the WASPostUpgrade command from the bin directory
of the Version 6 installation root.
- You receive error: MIGR0253E: The backup directory migration_backup_directory
does not exist.
Several possible reasons for this error
exist:
- The WASPreUpgrade tool was not run prior to the WASPostUpgrade tool.
- Check to see if the backup directory specified in the error message exists.
- If not, run the WASPreUpgrade .bat or .sh file.
- Retry the WASPostUpgrade tool.
An invalid backup directory might be specified. For example, the directory
might have been a subdirectory of the V4.0.x or V5.x tree, which was deleted
after the WASPreUpgrade tool was run and the older version of the product
was uninstalled, but before the WASPostUpgrade tool was run.
- Determine if the full directory structure specified in the error message
exists.
- If possible, rerun the WASPreUpgrade tool, specifying the correct full
migration backup directory.
- If the backup directory does not exist, and the older version it came
from is gone, rebuild the older version from a backup repository or XML configuration
file.
- Rerun the WASPreUpgrade tool.
- You decide that you need to run WASPreUpgrade again after you
have already run WASPostUpgrade. During the course of a deployment
manager or a managed node migration, WASPostUpgrade disables the old environment.
If, after running WASPostUpgrade, you want to run WASPreUpgrade again against
the old installation, you must execute the migrationDisablementReversal.jacl
script located in the old install_root/bin directory. After executing
this .jacl script, your V5.x environment will be in a valid state again, allowing
you to run WASPreUpgrade to produce valid results. For more information on
scripting, see Getting started with scripting.
- The SOAP/RMI call up to the deployment manager times out.
During the course of a federated migration, the migration process makes
a call up to the DeploymentManager to perform a portion of the migration.
If, after seeing the message MIGR0388I, you see a SOAP/RMI connection
timeout exception, rerun WASPostUpgrade specifying the "-connectionTimeout"
to some value greater than the default (the default is 10 minutes). A good
rule of thumb is to double the value and execute WASPostUpgrade again.
- A federated migration fails with message MIGR0405E.
The migration that has taken place on your deployment manager as part
of your federated migration has failed. For a more detailed reason of why
this error has occurred, open the folder yourNodeName_migration_temp
located on your deployment manager node under the ...DeploymentManagerProfile/temp
directory. Example:
/websphere60/appserver/profiles/dm_profile/temp/nodeX_migration_temp
The
logs, traces, and everything else involved in the migration for this node
on the deployment manager node are located in this folder. This folder will
also be required for IBM support related to this scenario.
- V6 applications are lost during migration. During
a federated migration, if any of the V6 applications fail to install, they
will be lost during the syncing of the configurations. The reason this happens
is that one of the final steps of WASPostUpgrade is to execute a syncNode command.
This has the result of downloading the configuration on the deployment manager
node and overwriting the configuration on the federated node. If the applications
fail to install, they will not be in the configuration located on the deployment
manager node. To resolve this issue, manually install the applications after
migration. If they are standard V6 applications, they will be located in
the WAS_ROOT/installableApps directory.
- V6 applications fail to install. Manually install
the applications using wsadmin after
WASPostUpgrade has completed.
Note: During a managed node
migration, applications that are new to V6 and belong to a server that was
previously part of a cluster in V5 can fail to install. To fix this problem:
- Run a syncNode to sync the configuration data up with the deployment manager's
master repository.
- Install the applications manually through wsadmin or the administrative
console.
- General issues:
- When migrating a deployment
manager, the Version 6 cell name must match the Version 5.x cell name. If
you create a profile with a new cell name, the migration will fail.
- When migrating a federated
node, the new cell name and node name must match their respective Version
5.x names.
- If you create a profile that does not meet the
migration requirements (such as naming requirements), you can remove the old
profile and create
new one, rather than uninstalling and re-installing the Version 6 product.
- If you migrate a node to Version 6, then discover that you need
to revert back to Version 5.x, see Rolling back your environment to V5.x.
- If none of these errors describes your problem:
- For general tips on migration problems, see Troubleshooting the migration
utility.
- Review the migration topic and its subtopics, which address
migrating specific kinds of components.
- For other kinds of migration problems, such as an application
imported from another version of WebSphere Application Server that will not
start, look up the related problem under Troubleshooting by task.
- Check to see if the problem has been identified and documented
by looking at the IBM Support page.
- IBM Support has documents that can save you time gathering information
needed to resolve this problem. Before opening a PMR, see the IBM Support page.