This section explains how to plan your migration. Complete the following
steps:
- Decide how you want to migrate the product components:
- 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.
- 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.
The following topics describe
different migration scenarios:
- 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.
- 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
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.
- Decide how you want to use your existing resources with WebSphere
Event Broker Version 6.0.
Except for user-defined extensions,
you do not need to perform any tasks to migrate your development and deployment
resources, such as message flow 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 .
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 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
- 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.
- 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.