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
- When migrating a standalone application server or a deployment manager
- 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)
- When migrating a managed node
- Location: New configuration relative to the new profile_root directory
Note: Federated
migration is unique in that it is a two-stage process. Half of the federated
migration takes place on the managed node and the other half takes place on
the deployment manager. This process requires a temporary work area located
on the deployment manager under the
temp directory:
profile_root/temp/managed_node_migration_temp
- Amount:
- For a rough estimate of your storage requirements for the first stage
when using this command, add the following amounts.
- Size of the following items for the old profile of the managed node 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 a rough estimate of your storage requirements for the second stage
when using this command, add up to 200 MB (depending on the size and complexity
of your configuration) for tracing.
During the second stage of federated
migration, tracing is enabled and cannot be disabled.
Important: The
trace files for a federated migration are created in the temporary work area
located on the deployment manager in the
profile_root/temp/managed_node_migration_temp directory. Even after a successful migration,
however, the federated-migration process does not delete this directory. This
might cause storage issues if you run multiple federated migrations on different
nodes without cleaning up this temporary directory because each node will
get its own temporary work area located on the deployment manager.
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 deployment
manager is 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 deployment manager directories after
running WASPostUpgrade.
This must be done before starting the Version 6.0.x deployment manager.
- 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.
- High availability manager and
core group functionality are included in WebSphere Application Server Version
6.0 and later. See Core group migration considerations for core
group configuration and topology considerations that might impact your migration
from to Version 6.0.x.