The goal of migration is to reconstruct your earlier version in
a nearly identical Version 6.0.x environment, including applications, configuration
settings, universal resource identifier (URI) descriptors, and Web server
context roots. The goal of coexistence is to create a mixed-version environment
that is not in conflict; this allows the nodes of all versions to start and
run at the same time.
The migration tools migrate
applications and configuration information to the new version as described
in Migrating product configurations.
The Migration
wizard is new for Version 6.0; it provides a graphical user interface
to the migration tools. The Migration wizard can call the migration tools,
or you can run them directly.
Table 1. Overview of migrating
from release to release
Migration path |
Description |
Version 5.x to Version 6.0.x |
The migration from Version 5.x to Version 6.0.x is fairly
routine. Important reference articles for this migration include:
|
Version 4.0.x to Version 6.0.x |
The migration tools perform a fairly routine migration
from Version 4.x to Version 6.0.x. For example, Java 2 Platform, Enterprise
Edition (J2EE) 1.2 enterprise archive (EAR) files in Version 4.x work in Version
6.0.x of WebSphere Application Server, which supports the J2EE 1.4 specification.
Similarly, it is not necessary to redeploy enterprise Java bean (EJB) 1.1
Java archive (JAR) files when moving them from Version 4.x to Version 6.0.x,
which also supports EJB 2.0 JAR files. Also be aware that in Version 6.0.x,
the statement cache size setting described in WebSphere Application Server data source properties is different from WebSphere Application
Server Version 4.0.x. In Version 4.0.x, the maximum number of possible prepared
statements is cached for the data source within an application server. In
Version 5.0 and later, statement cache size is defined on a given physical
connection. |
If you neither migrate nor coexist with an earlier version of WebSphere
Application Server, you are choosing to ignore the previous installation,
and you can run only one version at a time because of conflicting default
port assignments. It is possible for both versions to run at the same time
without conflict if you use non-default ports in the earlier version. To setup
coexistence with Version 4.0.x or Version 5.x, ensure that unique ports are
selected during profile creation for the Version 6.0.x installation. To set
up coexistence with Version 6.0.x, select the radio button that states "Install
a new copy of the V6 Application Server product" during installation.
You can resolve conflicting port assignments by specifying port assignments
for coexistence during profile creation, by wsadmin scripting, or by
using the Servers > Application Servers > server1 > End Points administrative
console page to ensure that Version 6.0.x can run with an earlier version.
Coexistence processing changes the following configuration files:
- The virtualhosts.xml file:
- HTTP Transport Port
- IBM HTTP Server Port
- HTTPS Transport Port
- HTTP Administrative Console Port
- HTTPS Administrative Console Secure Port
- The serverindex.xml file:
- Bootstrap Address
- SOAP Connector Address
- DRS Client Address
- SAS SSL ServerAuth Listener Address
- CSIV2 SSL ServerAuth Listener Address
- CSIV2 SSL MutualAuth Listener Address
- WC adminhost
- WC defaulthost
- DCS Unicast Address
- WC adminhost secure
- WC default secure
- SIB Endpoint Address
- SIB Endpoint Secure Address
- SIB MQ Endpoint Address
- SIB MQ Endpoint Secure Address
See
Port number settings in WebSphere Application Server versions for
more information.
Consider
these issues in a migration or coexistence scenario:
- The amount of storage that your system requires during migration to Version
6.0.x 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 your 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 your configuration)
For more information about this command, see WASPostUpgrade command.
- There might be conflicting context roots when attempting to share the
same Web server.
Follow the procedure in Migrating Web server configurations to learn how to configure a Web server for sharing between
WebSphere Application Server versions.
- If your application server has been configured to run as non-root, follow
the instructions in Migrating a previously non-root configuration to root to
change the ownership and file permissions of the node directories after running WASPostUpgrade.
This
must be done before starting the Version 6.0.x application server.