Plan the order and extent of the steps you must complete to migrate components and resources to Version 6.0.
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.
You must perform specific 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, only if you have user-defined extensions and mapping files,
You can start using these resources with WebSphere Message 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 and message sets are used; read the guidance provided in Message flow migration notes and Message set migration notes.
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.
The changes in converters between WebSphere Business Integration Message Broker Version 5.0 and WebSphere Message Broker Version 6.0 are significant, therefore the set of converters from the previous level has been included with WebSphere Message 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.
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.
Each 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.
After you have planned your migration, back up your resources.