Troubleshooting migration

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.

(dependent on configuration)

• The following problems can occur when using the pre-upgrade tool:

  1. 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.

  2. 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.

  3. 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.

       1. 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.

       2. 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.

  4. 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.

• The following problems can occur when using the post-upgrade tool:

  1. 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.

  2. 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.

  3. 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.

       1. 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.

       2. 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.

  4. 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.

  5. 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.

       1. Check to see if the backup directory specified in the error message exists.

       2. If not, run the WASPreUpgrade .bat or .sh file.

       3. 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.

       1. Determine if the full directory structure specified in the error message exists.

       2. If possible, rerun the WASPreUpgrade tool, specifying the correct full migration backup directory.

       3. 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.

       4. Rerun the WASPreUpgrade tool.

  6. 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, 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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:

      1. Run a syncNode to sync the configuration data up with the deployment manager's master repository.

      2. Install the applications manually through wsadmin or the administrative console.

• General issues:

  1. 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.

  2. When migrating a federated node, the new cell name and node name must match their respective Version 5.x names.

  3. 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.

  4. 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:

  1. For general tips on migration problems, see Troubleshooting the migration utility.

  2. Review the migration topic and its subtopics, which address migrating specific kinds of components.

  3. 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.

  4. Check to see if the problem has been identified and documented by looking at the IBM Support page.

  5. 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.

What to do next