Planning for migration from Version 2.1

Before you start:

Before you carry out any migration tasks, back up Version 2.1 resources and read Coexistence with previous versions and other products.

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:
  1. Decide how you want to migrate the product components:
    1. 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.
    2. 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.
    3. 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.
    4. 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.

  2. 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

  3. 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.

  4. 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.
Related tasks
Backing up Version 2.1 resources
Migrating from Version 2.1 products
Related reference
mqsimigratecomponents command