Make sure that Control Center users
have checked in all WebSphere MQ Integrator
Broker resources.
Back up all configuration repository, message repository, and broker
database tables.
Decide which message flows and message sets you want to migrate
and use in the WebSphere Message
Broker broker domain and
export them:
Stop any debugging sessions in the Control Center. It is not possible to migrate message flows that are being debugged.
Using a Control Center session in
which all the required message flows are visible in the workspace, export
the message flows. Save the export files in a directory other than the one
in which WebSphere MQ Integrator
Broker is installed. The
export files also contain information about the user-defined nodes that are
used by the message flows.
Alternatively, on the system where the Configuration
Manager is
running, export all the required Version 2.1 message
sets using the mqsiimpexpmsgset command with the -e parameter. Save the export files in a directory
other than the one in which WebSphere MQ Integrator
Broker is
installed.
Decide how you are going to migrate the brokers:
Decide which brokers you no longer require after migration.
Decide which brokers you want to migrate from Version 2.1 to Version 6.0.
Decide which brokers you want to preserve at Version 2.1.
If two or more of the brokers share the same
set of database tables, and you still require these brokers after migration,
either migrate all of the brokers at the same time or preserve them all at Version 2.1.
For each broker that you want to migrate from Version 2.1 to Version 6.0, and for the associated assignments configuration data
you want to preserve, record the information in the following list. Record this information manually from a Control Center session
or export everything in the Control Center workspace
by clicking File > Export All
in Workspace, save the export file in a directory
other than the one in which WebSphere MQ Integrator
Broker is
installed and extract the required information from the export file. (To find
out how to do this, see Assignments configuration data in an export file.) Record:
The name of the broker
The name of each message set that is assigned to the broker
The name of each execution group within the broker
For each execution group within the broker, the name of each message flow
that is assigned to the execution group
For each message flow assigned to an execution group, the following properties:
Additional instances
Commit count
Commit interval
Coordinated transaction
Decide whether you want to preserve the following configuration
data, which is stored in the configuration repository:
Assignments data
Topology data
Topics data
Unless you decide that you no longer require any of your existing brokers
after migration, you must preserve this configuration data.
Decide which components of WebSphere Message
Broker you
want to run on each of your systems after migration.
Consider
the following criteria when making your decision:
A broker must run on the same system and use the same queue manager as
it did before migration, unless you decide that you no longer need the broker
after migration.
The Configuration
Manager must run on the same system
and use the same queue manager as it did before migration, unless you decide
not to preserve the assignments, topology, and topics data in the configuration
repository.
A workbench can run on any system after
migration. It does not have to run on a system where Control Center sessions
used to run.
To avoid adding unnecessary complexity to the migration process itself,
run a User Name Server on the same system, and configure
it to use the same queue manager as it did before migration. If required,
change the location of a User Name Server and the
queue manager it uses after successful migration.
You do not need to change the configuration of a queue manager
that is preserved during migration. You might, however, need to ensure that
the WebSphere MQ product code is at the required
release and service level to support WebSphere
Message Broker Version 6.0.
At the same time, you might want to ensure that you have installed the other
software prerequisites.
If you are not able to stop a broker during
migration because it is doing critical work, but you want to migrate the broker
to Version 6.0:
Create a new Version 2.1 broker on a system
on which you are not going to install WebSphere Message
Broker.
Using a Control Center session, deploy to the
new broker all the configuration data that was deployed to the original broker.
The new broker can then take over the work of the original broker during
the migration.
Decide where you are going to store the development data that is
created and maintained in the workbench. Store the data in the local file system, on a shared drive, or in a
shared repository that is supported by Eclipse. The instructions for the individual
migration tasks assume that you are using the local file system or a shared
drive.
When you are ready to migrate, run the mqsimigratecomponents command
with the -c parameter. This performs a pre-migration
check against the Version 2.1 components to
ensure that they can be migrated. The pre-migration check identifies any potential
problems and allows you to correct them before proceeding with migration.
When you have run the pre-migration
check successfully, you are ready to perform migration. There are three scenarios
for migration to Version 6.0: