This section explains the different ways in which to migrate from Version 2.1 to Version 6.0.
Before carrying out any migration tasks, you should make the following decisions:
- Decide how you want to migrate the product components:
- Find out what is new in Version 6.0.
These new and changed functions might affect how you want to use your migrated
components in the future.
- Decide where you want to migrate the product components. Migrate
your components to the same computer or to a second computer. For example,
you might want to migrate components to another location to maintain availability
during the migration.
- Decide when you want to migrate the product components. You
might want to preserve some components at the Version 2.1 level
of code temporarily, and migrate them later.
- Decide the order in which you want to migrate your components.
You can migrate components in any order, but your specific circumstances might
mean that you need to migrate components in a particular order.
See Coexistence with previous versions and other products for information about how Version 6.0 can coexist on the same computer with Version 2.1, and how Version 6.0 components
can operate with Version 2.1 components.
- Decide how you want to use your existing resources with WebSphere Message Broker Version 6.0.
You migrate your Version 2.1 message
flows, message sets, and user-defined extensions using
the mqsimigratemsgflows command and mqsimigratemsgsets command.
The tooling part of any Version 2.1 user-defined
extensions that you have migrated needs to be rewritten in Version 6.0.
Decide which user-defined extensions you want to use in Version 6.0 and
re-create them in the Version 6.0 tooling.
When
you start using your resources in the Version 6.0 Message Brokers Toolkit, there are restrictions to using
these same resources again with the Version
5.0 or Version 5.1 Message Brokers Toolkit.
For more information, see Conditions for using migrated resources with previous versions of the Message Brokers Toolkit
- Decide whether you need to carry out any testing to ensure a successful
migration.
Migrating your development and test
domains before migrating your production domain allows you to identify problems and develop a strategy for dealing with
further problems.
- 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 potential
problems and allows you to correct them before proceeding with migration.
You do not need to change the configuration of a queue manager that
is preserved during migration.
The other topics
in this section provide instructions for different migration scenarios: