Migrate a deployment manager from an older version to a
newer version of WebSphere® ESB using
the command-line tools.
Before you begin
Note: In a WebSphere ESB network
deployment cell, the deployment manager must always be in a WebSphere ESB profile.
Note: Migrate the
WebSphere ESB version 6.0.x or 6.1.x deployment
manager to
version 6.2 before
migrating the managed nodes that comprise the cell. The deployment
manager must always be at the highest release and fix level within
a cell in order for it to manage all nodes in the cell.
A version 6.2 deployment
manager can manage version 6.1.x and version 6.2 managed
nodes. For migrations from version 6.1.x,
this allows a cell to be upgraded to a new release one node at a time,
with minimal impact to the applications that are running within the
cell. For migrations from version 6.0.2.x,
to keep the cell running with minimal down time, you must migrate
to version 6.2 in
two stages: first from version 6.0.2.x to version 6.1.x,
and then from version 6.1.x to version 6.2. Alternatively
you can shut down the entire cell and migrate in a single step, directly
from version 6.0.2.x to version 6.2. 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.
Make sure that the following conditions
are met before you start the migration process:
- Your system meets all the hardware and software requirements for
the new version of WebSphere ESB.
- You have installed the new version of WebSphere ESB side-by-side
the previous version on the same system.
- A deployment manager profile, created with the older WebSphere ESB version,
resides on the same system.
- Sufficient disk space is available for the migrated profile and
its backup. See Premigration considerations for WebSphere ESB for details
about disk space requirements.
Make sure that you have completed the following tasks before
you start the migration process:
- Back up the databases that support version 6.0.2.x or version 6.1.x WebSphere ESB components.
Procedure
- Log on using one of the following procedures,
depending on your operating system.
On i5/OS® platforms: Log
on with an i5/OS user
profile that has *SECOFR user class or *ALLOBJ special
authority.

On Linux® and UNIX® platforms: Log on as the
root user.
On Windows® platforms: Log
on as a member of the Administrator group.
- Identify, in advance, the pre-existing
information required by the migration wizard, as listed below:
- Cell name
- Name of the cell managed by the deployment manager that you are
migrating. The new version cell name must match the name in the old
version's configuration.
- Node name
- Name of the node that you are migrating. The new version node
name must match the name in the old version's configuration.
- Stop the deployment manager that you are
about to migrate. Use the stopManager command
from the deployment manager's profile_dir/bin directory
or from the deployment manager's First steps console.
For more
information about the stopServer command see the stopServer command. Use
the following syntax:Note: On i5/OS platforms,
you must run the scripts under QSHELL. To start a QSHELL session,
open a CL command prompt and type QSH.
On i5/OS platforms: profile_root/bin/stopManager

On Linux and UNIX platforms: profile_root/bin/stopManager.sh
On Windows platforms: profile_root\bin\stopManager.bat
If security is enabled, use one of the following commands instead.
The user name provided must be a member of the operator or administrator
role.
On i5/OS platforms: profile_root/bin/stopManager
-username user_ID -password password

On Linux and UNIX platforms: profile_root/bin/stopManager.sh
-username user_ID -password password
On Windows platforms: profile_root\bin\stopManager.bat
-username user_ID -password password
Note: You must stop the previous version deployment manager
before you start the migration process. If you do not, any configuration
changes you make during migration process will not be migrated to
the target profile.
- Run the WBIPreUpgrade command,
specifying the migration backup directory name and the existing WebSphere ESB directory
name. The WBIPreUpgrade tool saves
selected files from the install_root and profile_root directories to
a backup directory you specify. See the WBIPreUpgrade command-line utility for
details.
- Run the WBIPostUpgrade command,
specifying the migration backup directory. The WBIPostUpgrade tool
restores the backed up configuration in the backup directory into
the new WebSphere ESB Deployment
Manager profile. See the WBIPostUpgrade command-line utility for details.
Important: Use the
-createTargetProfile parameter
when invoking
WBIPostUpgrade. This option creates
a matching required new target profile for migration. For more information
about target profiles, refer to
Target profile considerations.
Note: If you are migrating on an
i5/OS platform, the target profile name
must match the profile name of the source profile being migrated.
- If you are migrating from version 6.0.2 to version 6.2.x you need to create the common database.
For information, see Creating
the common database and configuring the recovery subsystem when migrating
from version 6.0.2 to version 6.2.x.
- If you need to manually update the Common
database, do so now.
Note: This task only applies when
migrating from version 6.1 to version 6.2.
See Upgrading the Common database manually for instructions.
Normally, database changes required by new versions of WebSphere ESB are
made automatically. When the server is first started the database
tables are migrated to the new schema version. However, in cases in
which the server has insufficient permissions to access the database
schema, or other database-specific requirements are not met, you must
update the database manually.
- Start the version 6.2 deployment
manager.
CAUTION:
When the version 6.2 deployment
manager is started, the federated nodes synchronize with the migrated
deployment manager. This synchronization causes the applications to
be reinstalled. If you have any applications running on active servers,
those applications will appear to restart and be unavailable for a
very short time.
To start the deployment manager,
use the startManager command from the profile_dir/bin directory
or the First steps console. See startManager command for more information
on the startManager command.
- Optional: Uninstall the version 6.0.x or 6.1.x deployment
manager.
Perform this step only after you are certain
that you have successfully migrated the configuration of the deployment
manager that you intend to delete. For more information about uninstalling,
see Uninstalling the software.
Results
Your deployment manager is now migrated.
What to do next
Verify that the migration has been successful.