Premigration considerations

 

Before you begin the process of migrating to WebSphere Application Server V6.1, there are some considerations of which be aware.

• After you have installed WebSphere Application Server V6.1, you might want to build a complete deployment cell configuration and make sure that it works properly before you attempt to migrate an existing cell or node.

  This ensures that your system has all of the necessary prerequisites and supports the new level of WAS.

• High availability manager and core group functionality are included in WAS V6.0 and later. See Core group migration considerations for core group configuration and topology considerations that might impact your migration from Version 5.x or 6.0.x to V6.1.

• Before you migrate to JDK 5 (introduced in WebSphere Application Server V6.1) from JDK 1.4 (introduced in V5.1) or JDK 1.3 (supported in V5.0.x) , review your applications for necessary changes based on the Sun Microsystems Java specification.

  See API and specification migration.

• When migrating a cell with multiple nodes, the applications must remain at lowest JDK level until all nodes are migrated.

• Java Native Interface (JNI) applications that work with WAS V6.0.2 on Solaris x64 must be recompiled in a 64-bit environment in order for them to work with WebSphere Application Server V6.1. This includes all JNI applications that run in a WAS process—code called from an Enterprise JavaBean (EJB) for example.

  On Solaris x64, WAS Version 6.0.2 runs as a 32-bit application even though the underlying platform is 64-bit. This is because the underlying Java virtual machine is 32-bit. WebSphere Application Server V6.1 runs as a 64-bit application because the underlying Java virtual machine is 64-bit. JNI applications compiled in a 32-bit environment for V6.0.2 cannot run in the 64-bit environment of V6.1.

• The Web server plug-in configuration file (plugin-cfg.xml) generated after successful migration from V5.x to V6.x is topology centric—that is, it includes all the applications within a cell. You cannot manage this cell-wide plug-in configuration file from the console until you have manually configured it.

  See Migrating Web server configurations.

• The migration articles assume that WAS Version 6.1 is being installed in an environment where it must coexist with prior levels of WAS. Consider the following items while planning to enable coexistence:

  • Update prerequisites to the levels required by WAS V6.1.

    Prior levels of WAS will continue to run at the higher prerequisite levels.

  • Review the ports defined to ensure that the WebSphere Application Server V6.1 installation does not conflict.

    In particular, note that the default daemon port definition for both versions is the same when installing to coexist with WAS V5.x or 6.0.x.

    See Port number settings in WAS versions for default port information.

  See Coexisting.

• Consider the following if you are planning to have any mixed-release cells:

  • You can upgrade a portion of the nodes in a cell to WebSphere Application Server V6.1 while leaving others at the older release level. This means that, for a period of time, you might be administering servers that are at the current release and servers running the newer release in the same cell.

    Note that in this mixed-release environment, there might be some restrictions on what you can do with servers at the older release level. For details, see Creating appservers. There might also be restrictions on creating clusters and cluster members. For details, see Creating clusters.

  • A WAS V6.1 deployment cell can contain mixed releases of V5.x or 6.0.x nodes, but there is no mixed-node management support for V6.0.0.x and V6.0.1.x. The V6.1 migration tools still migrate these nodes during deployment-manager migration, but they issue a warning message that the nodes cannot be managed by the V6.1 deployment manager. You can then do one of the following based on your needs.

    • Upgrade all V6.0.0.x and V6.0.1.x nodes to at least Version 6.0.2. This will allow them to be administered by a V6.1 deployment manager.

    • Immediately migrate these nodes to V6.1.

• During migration, V6.1 cluster information is distributed throughout the cell. V6.0.x nodes that are not at V6.0.2.11 or later fail to read this information and the cluster function might fail. Therefore, upgrade all V6.0.x nodes that will be contained in or interoperating with a V6.1 cell to V6.0.2.11 or later before migrating your deployment managers to V6.1.

• WAS V6.1 migration converts HTTP transports to channel-framework Web container transport chains.For more information on WAS V6.1 transport support, see the following articles:

  • Configure transport chains

  • HTTP transport channel settings

  • Transport chains

• The default profile location was changed in WAS V6.0.x. The old file path $WAS_HOME/profiles/<profile>/<node>/installedApps/<ear>/<war> is now $WAS_HOME/profiles/<profile>.

  To avoid configuration problems, use servlet APIs to control the file location instead of using the default location.

• When migrating a deployment manager, the WAS V6.1 cell name must match the Version 5.x or 6.0.x cell name.

  If you create a profile with a new cell name, the migration will fail.

• When migrating a federated node, the WAS V6.1 cell name and node name must match their respective V5.x or 6.0.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 a new one rather than uninstalling and reinstalling the WebSphere Application Server V6.1 product.

• If you migrate a node to WebSphere Application Server V6.1 then discover that revert back to V5.x or 6.0.x, see Rolling back your environment.

• If you have a Web services gateway running on a WAS V5.x or 6.0.x appserver that is part of a ND cell and you want to migrate the cell from a V5.x or 6.0.x to a V6.1 deployment manager, first preserve the gateway configuration as described in Coexisting with previous gateway versions.

• The migration tools create a migration backup directory containing a backup copy of the configuration from the previous version. Here are some guidelines that might help you to determine the amount of file-system space that this directory might require.

  • If you are migrating from V5.x, the space available for this directory should be at least the size of the previous version's configuration directory and applications plus the size of the configuration directory and applications for any wsinstances that you have defined.

  • If you are migrating from V6.0.x, the space available for this directory should be at least the size of the previous profile's configuration directory and applications.

• The amount of storage that your system requires during migration to Version 6.1 depends on your environment as well as on which migration tool you are using.

   

  • WASPreUpgrade storage requirements

     

    • Location: Backup directory specified as a parameter of the WASPreUpgrade command

       

    • Amount: For a rough estimate of your storage requirements when using this command, add the following amounts.

      • Size of the following items for all of the profiles in your old configuration:

        • profile_root/installableApps directory

        • profile_root/installedApps directory

        • profile_root/config directory

        • profile_root/properties directory

        • Shared libraries referenced in the libraries.xml configuration files

        • Resource Adapter Archive (RAR) files referenced in the resources.xml configuration files

      • If trace is enabled, which is the default, up to 200 MB (depending on the size and complexity of the configuration)

    For more information about this command, see WASPreUpgrade command.

     

  • WASPostUpgrade storage requirements

     

    • Location: New configuration relative to the new profile_root directory

       

    • Amount: For a rough estimate of your storage requirements when using this command, add the following amounts.

      • Size of the following items for the old profile that you are migrating:

        • profile_root/installableApps directory

        • profile_root/installedApps directory

        • profile_root/config directory

        • profile_root/properties directory

        • Shared libraries referenced in the libraries.xml configuration files

        • Resource Adapter Archive (RAR) files referenced in the resources.xml configuration files

      • If trace is enabled, which is the default, up to 200 MB (depending on the size and complexity of the configuration)

    For more information about this command, see WASPostUpgrade command.

• Before you migrate a Cloudscape database, ensure that any appservers hosting applications that are using the Cloudscape database are shut down. Otherwise, the Cloudscape migration will fail.

• After you use the migration tools to migrate to WebSphere Application Server V6.1, you might need to do some things that are not done automatically by the migration tools.

  • Examine any LTPA (LTPA) security settings that you might have used in WebSphere Application Server V5.x or 6.0.x, and make sure that V6.1 security is set appropriately.

    See LTPA.

  • Check the WASPostUpgrade.log file in the logs directory for details about any JSP objects that the migration tools did not migrate.

    If V6.1 does not support a level for which JSP objects are configured, the migration tools recognize the objects in the output and log them.

  • Review your Java virtual machine settings to verify that you are using a heap size of at least 50 for improved startup performance.

    See Java virtual machine settings.

    If you have used a smaller heap size in the past, you can use the default heap size of 50.

  • Verify the results of the automatic Cloudscape database migration, and manually migrate any Cloudscape databases that are not automatically migrated by the tools.

    See Migrating Cloudscape databases.

---

 

Related information

Migrating and coexisting