Planning for migration from Version 5.0

This section explains how to plan your migration. Complete the following steps:
  1. Decide how you want to migrate the product components:
    1. Find out what is new in Version 6.0 and learn about new and changed function. These changes might affect how you want to use your migrated components in the future.
    2. Decide where you want to migrate the product components. Migrate them to a different location on 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 5.0 level for now, 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.

    Coexistence with previous versions and other products shows you how WebSphere Message Broker Version 6.0 can coexist on the same computer with previous versions of the product, and how Version 6.0 components can operate with components from previous versions.

  2. Decide how you want to use your existing resources with WebSphere Message Broker Version 6.0.

    Except for user-defined extensions and mapping files, you do not need to perform any tasks to migrate your development and deployment resources, such as message flow files, message set definition files, ESQL files, XML Schema files, and broker archive files. You can start using these resources with WebSphere Message Broker Version 6.0 immediately.

    All Version 5.0 and Version 5.1 user-defined node projects must be upgraded to work with the Version 6.0 Message Brokers Toolkit. Upgrade a project by cleaning it: click Project > Clean. When you clean a project, the extension point that is required by Version 6.0 to compile the ESQL files contained in the user-defined extension is created in the project plugin.xml file.

    After you have migrated Version 5.0 mapping files (.mfmap) to Version 6.0 mapping files (.msgmap) using the mqsimigratemfmaps command, edit them in the Version 6.0 Message Brokers Toolkit. There is no migration tool to migrate a mapping that is called from ESQL.

    After you start using your current resources in the Version 6.0 Message Brokers Toolkit, there are then restrictions on reusing these same resources 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.

    The purpose of testing your migration is to identify any problems that might arise during migration. For example, if problems arise you might need to restore some migrated resources to the Version 5.0 level that you backed up before you started the migration, and any post-migration changes to these resources would be lost. Migrating your development and test domains before migrating your production domain allows you to identify problems like this and develop a strategy for dealing with further problems.

  4. Optional: When you are ready to migrate, run the mqsimigratecomponents command with the -c parameter. This performs a pre-migration check against the Version 5.0 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.

After you have planned your migration, back up your resources.

Related tasks
Migrating from Version 5.0 products
Planning to migrate a small domain
Planning to migrate a large domain
Planning to migrate multiple domains
Planning to migrate a high-availability domain
Migrating a user-defined node
Restoring migrated components to previous versions
Related reference
mqsimigratecomponents command