Before you begin the process of migrating to a new version
of WebSphere® ESB,
you should be aware of these considerations.
The following rules, restrictions, and considerations apply to
migration and coexistence if you have WebSphere ESB version 6.2 installed.
WebSphere ESB installation
requirements
- WebSphere ESB version 6.2 can be
installed in an environment where it coexists with prior levels of WebSphere ESB.
Augmentation
- You can migrate a version 6.0.2.x or version 6.1.x profile
to a version 6.2 profile
only if they are at the same augmentation level.
- You can have a mixed cell containing both augmented and unaugmented
managed nodes as long as the deployment manager for the cell has been
augmented to the same augmentation level as the highest augmentation
level of any of its managed nodes. For example, if the deployment
manager is augmented for WebSphere ESB, it
can successfully manage nodes that have been augmented for WebSphere ESB and WebSphere Application Server. However,
a deployment manager that has been augmented only for WebSphere Application Server can manage
only WebSphere Application Server nodes.
Backup directory
- The migration tools create a migration backup directory containing
a backup copy of the configuration from the previous version. The
space available for this directory should be at least the size of
the previous profile's configuration directory and applications. The
previous profile can be either a WebSphere ESB or WebSphere Application Server profile.
Note: When
you migrate from version 6.0.2.x,
all of the existing profiles under the previous installation of WebSphere ESB are
backed up. However, when you migrate from version 6.1.x,
only one profile at a time is backed up.
Clusters
- Members of a cluster cannot be running different versions (6.0.2.x,
6.1.x, 6.2) of WebSphere ESB. If
you have configured a cluster containing servers running different
versions, all the members running earlier versions of WebSphere ESB must
be stopped before you start the first version 6.2 cluster member.
Also, once you start a version 6.2 cluster member, do not start any version 6.1.x or 6.0.2.x cluster
members in that cluster.
Databases
- Before you migrate a Cloudscape or
Derby database, ensure that any servers hosting applications that
are using the Cloudscape database
are shut down. Otherwise, the Cloudscape migration
will fail.
HTTP transport
WebSphere ESB version 6.0.2.x migration
converts HTTP transports to channel-framework Web container transport
chains.
Note: This applies only to migrations from version 6.0.2.x.
For
more information on
version 6.2 transport
support, see the following topics:
Java/JDK (Java Development Kit)
Important: Ensure that all generic
JVM (Java Virtual Machine) parameters specified for any server are
compatible with the new Java version. Remove them if they aren't.
Check other JVM related applications such as Wily Agents, because
you may have to adopt them to the new Java version. Be sure to disable
them prior to the migration and then enable them after the migration.
JNI (Java Native Interface)
Java Native
Interface (JNI) applications that work with WebSphere ESB version
6.0.2 on Solaris x64 must be recompiled in a 64-bit environment in
order for them to work with WebSphere ESB version 6.2. This
includes all JNI applications that run in a WebSphere ESB process—code
called from an Enterprise JavaBean (EJB) for example. On Solaris
x64, WebSphere ESB 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 ESB version 6.2 runs
as a 64-bit application because the underlying Java virtual machine is 64-bit. JNI applications
compiled in a 32-bit environment for version 6.0.2 cannot run in the
64-bit environment of version 6.2.
Rolling back
environments
- If you migrate a node to WebSphere ESB version 6.2, then
discover that you need to revert back to version 6.0.x or 6.1.x, see Rolling back your environment.
Storage
- The amount of storage that your system requires during migration
to version 6.2 depends
on your environment as well as on which migration tool you are using.
- WBIPreUpgrade storage requirements
- Location: Backup directory specified as a parameter of
the WBIPreUpgrade 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 WebSphere ESB or WebSphere Application Server 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 the WBIPreUpgrade command-line utility.
- WBIPostUpgrade 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 WebSphere ESB or WebSphere Application Server 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 the WBIPostUpgrade command-line utility.

Ulimit
setting
- To avoid an error during post migration where there are too many
open files, make sure you increase the ulimit setting. For instructions
on increasing the ulimit setting, see Preparing Linux systems.