Planning for migration from Version 5.0

Plan the order and extent of the steps you must complete to migrate components and resources to Version 6.0.

This section explains how to plan your migration:
  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 use your migrated components in the future.
    2. Check the requirements for other products on which Version 6.0 components might have dependencies. Details of prerequisite and other optional products are in both the Installation Guide and the Installation reference section.
    3. Decide where to migrate the product components; 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. You might also consider moving the Configuration Manager to another operating system.
    4. Decide when to migrate the product components. You might decide to preserve some components at the Version 5.0 level for now, and migrate them later.
    5. Decide the order in which 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 Event 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 will use your existing resources with WebSphere Event Broker Version 6.0.
    Application resources

    You must perform specific tasks to migrate your development and deployment resources, such as message flow files and broker archive files, only if you have user-defined extensions,

    You can start using these resources with WebSphere Event Broker Version 6.0 immediately. However, some migration actions are performed automatically when you open or rebuild resources in the toolkit, and some behavioral changes might affect they way in which your message flows are used; read the guidance provided in Message flow migration notes.

    • You must upgrade all Version 5.0 and Version 5.1 user-defined node projects to work with Message Brokers Toolkit Version 6.0. 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 start using your current resources in the Message Brokers Toolkit Version 6.0, reuse of those resources is subject to restrictions in Message Brokers Toolkit Version 5.0 or Version 5.1. For more information, see Conditions for using migrated resources with previous versions of the Message Brokers Toolkit.

    Start of changeCode page convertersEnd of change
    Start of change

    The changes in converters between WebSphere Business Integration Event Broker Version 5.0 and WebSphere Event Broker Version 6.0 are significant, therefore the set of converters from the previous level has been included with WebSphere Event Broker Version 6.0.

    If you make use of converters in your Version 5.0 environment, you might need to take additional steps to ensure that you can continue to use them after migration. See Using converters from a previous level of the product for details of this task.

    End of change
  3. Decide what testing you will do 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. If you migrate your development and test domains before you migrate your production domain, you can identify problems like this and develop a strategy for dealing with further problems.

    Start of changeEach new release can include changes to address product defects that affect external behavior. If your applications depend on undocumented or erroneous behavior, you must test those applications and allow time during your migration schedule to make any necessary changes.End of change

  4. Optional: When you are ready to migrate, run the mqsimigratecomponents command with the -c parameter. This form of the command 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, which you can correct before proceeding with migration.
  5. Optional: Consider adding time to your migration plan to update resources in response to changes in product behavior. Every release includes enhancements and fixes to external behavior, for example a correction to conform to an external standard. If your resources depend on undocumented or incorrect behavior, you might need to make changes and test these resources to understand the implications in your business scenarios.

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

Related tasks
Migrating from Version 5.0 products
Planning to migrate a small domain from Version 5.0
Planning to migrate a large domain from Version 5.0
Planning to migrate multiple domains from Version 5.0
Planning to migrate a high-availability domain from Version 5.0
Migrating a user-defined node from Version 5.0 or Version 5.1
Restoring migrated components to previous versions
Using converters from a previous level of the product
Related reference
Installation Guide
mqsimigratecomponents command
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. All Rights Reserved.
Last updated : 2009-01-07 15:40:32

ah20650_