Migrating from WebSphere MQ Integrator Broker Version 2.1 to WebSphere Business Integration Message Broker Version 5.0

Before you start

Before you start this task, complete the following task:

This topic describes how to migrate a broker domain from WebSphere MQ Integrator Broker Version 2.1 to WebSphere Business Integration Message Broker Version 5.0. You can migrate from any service level of WebSphere MQ Integrator Broker Version 2.1 back to and including Fix Pack 2.

For information about which components of WebSphere MQ Integrator Broker Version 2.1 can coexist with those of WebSphere Business Integration Message Broker Version 5.0, see Conditions for a Version 2.1 broker participating in a Version 5.0 broker domain.

To migrate a broker domain from WebSphere MQ Integrator Broker Version 2.1 to WebSphere Business Integration Message Broker Version 5.0, perform the following steps:

  1. Using a Control Center session, delete all brokers that you no longer need after migration from the Topology view and redeploy the topology. Close this and all other Control Center sessions.

    For information about how to use the Control Center to perform this task, see WebSphere MQ Integrator Broker Version 2.1 Using the Control Center.

  2. On each system where one or more brokers are running, perform one of the following steps for each broker:
    • If you no longer require the broker after migration, stop the broker and delete it.
    • If you want to migrate the broker from Version 2.1 to Version 5.0, stop the broker but do not delete it.
    • If you want to preserve the broker at Version 2.1, do nothing. You do not have to stop it.

    On a UNIX or Windows system, stop the broker by issuing the mqsistop command with the name of the broker, and delete the broker by issuing the mqsideletebroker command with the name of the broker. For information about how to use these and other WebSphere MQ Integrator Broker commands, see the WebSphere MQ Integrator Broker Version 2.1 Administration Guide.

    For information about how to stop and delete a broker on z/OS, see the WebSphere MQ Integrator Broker for z/OS Version 2.1 Customization and Administration Guide.

  3. On the system where the Configuration Manager is running:
    1. Stop the Configuration Manager by issuing the mqsistop command for the component ConfigMgr.
    2. Optional: If you do not want to preserve the assignments, topology, and topics data in the configuration repository, delete the Configuration Manager by issuing the mqsideleteconfigmgr command with the -n and -m parameters. Using these parameters causes the configuration repository and the message repository to be deleted.
    3. Optional: If you want to preserve the assignments, topology, and topics data in the configuration repository, do not delete the Configuration Manager.
  4. On a system where a User Name Server is running, stop the User Name Server and delete it.

    On a UNIX or Windows system, stop the User Name Server by issuing the mqsistop command for the component UserNameServer, and delete the User Name Server by issuing the mqsideleteusernameserver command.

    For information about how to stop and delete a User Name Server on z/OS, see the WebSphere MQ Integrator Broker for z/OS Version 2.1 Customization and Administration Guide.

  5. On each system, except a UNIX or Windows system that is running a broker that you want to preserve at the Version 2.1 level, uninstall WebSphere MQ Integrator Broker. Follow the instructions in the appropriate book for your operating system:
    • WebSphere MQ Integrator Broker for AIX Version 2.1 Installation Guide
    • WebSphere MQ Integrator Broker for HP-UX Version 2.1 Installation Guide
    • WebSphere MQ Integrator Broker for Solaris Version 2.1 Installation Guide
    • WebSphere MQ Integrator Broker for Windows NT and Windows 2000 Version 2.1 Installation Guide

    On a Windows system, do not select the option to uninstall WebSphere MQ Integrator Broker completely, including data, if you want to preserve the assignments, topology, and topics data in the configuration repository or the data in broker database tables.

    On z/OS, you do not have to remove the WebSphere MQ Integrator Broker product code.

  6. On each system, except a UNIX or Windows system that is running a broker that you want to preserve at the Version 2.1 level, install the components of WebSphere Business Integration Message Broker that you require.
    For detailed instructions on how to perform this task, see:
  7. On the system where the Configuration Manager is going to run:
    1. Optional: If you are preserving the assignments, topology, and topics data in the configuration repository, migrate the data by issuing the mqsimigratetables command for the component ConfigMgr. At this time, do not use the -d parameter. For information about how to use this command, see mqsimigratetables command.
    2. Optional: If you are not preserving the assignments, topology, and topics data in the configuration repository and have previously deleted the Configuration Manager, create a new Configuration Manager by issuing the mqsicreateconfigmgr command. For detailed instructions on how to perform this task, see Creating a Configuration Manager on Windows.
    3. Start the Configuration Manager by issuing the mqsistart command for the component ConfigMgr. For detailed instructions on how to perform this task, see Starting and stopping the Configuration Manager.
  8. On each system where the workbench runs, perform the following steps:
    1. Start the workbench and connect it to the broker domain. In the Domains view of the Broker Administration perspective, make sure that you can see all the brokers that you have chosen to migrate: those that you are preserving at Version 2.1 level and those that you are migrating from Version 2.1 to Version 5.0. Close the workbench.

      See Creating a domain connection for detailed instructions on how to connect the workbench to the broker domain.

    2. Import the message flows that you want to migrate by issuing the mqsimigratemsgflows command. The command also imports information about the user-defined nodes that are used by the message flows. For detailed instructions on how to perform this task, see Migrating a message flow.
    3. Import the message sets that you want to migrate by issuing the mqsimigratemsgsets command. For detailed instructions on how to perform this task, see Migrating a message set.
  9. On a system where you have chosen to run a User Name Server, perform the following steps:
    1. Create the User Name Server by issuing the mqsicreateusernameserver command. On z/OS, configure the User Name Server. For detailed instructions on how to perform this task, see:
    2. Start the User Name Server. On a UNIX or Windows system, do this by issuing the mqsistart command for the component UserNameServer and, on z/OS, by starting the User Name Server task. For detailed instructions on how to perform this task, see:
  10. On each system where you are migrating one or more brokers from Version 2.1 to Version 5.0, perform the following steps:
    1. On a UNIX or Windows system, change the ODBC connection definition for each Oracle and Sybase database that is accessed by a broker. On AIX, also change the ODBC connection definition for each DB2 database that is accessed by a broker. Additionally, if a message flow that is running in a broker updates an Oracle or Sybase database within a global unit of work that is coordinated by the broker queue manager, change the XA resource manager definition for the database. To make these changes, follow the instructions in Changing the ODBC connection and XA resource manager definitions for a migrated broker.
    2. On a UNIX or Windows system, migrate the database tables of each broker by issuing the mqsimigratetables command with the name of the broker. If two or more brokers share the same set of database tables, migrate the database tables only once. On z/OS, configure each broker. Configuring a broker includes migrating its database tables.
    3. Create the new queues required by migrated brokers. On a UNIX or Windows system, create the queues by issuing the mqsimigratequeues command. On z/OS, you configured the broker during the previous step, so you have already created the new queues.
    4. Start each broker. On a UNIX or Windows system, issue the mqsistart command with the name of the broker or, on z/OS, start the broker task. For detailed instructions on how to perform this task, see:
    You do not need to do anything for the brokers that you are preserving at Version 2.1.
  11. On a system where the workbench runs, perform the following steps for each broker that you are migrating from Version 2.1 to Version 5.0:
    1. In the Domains view of the Broker Administration perspective, right-click the name of the broker then click Remove Deployed Children. All of the broker's execution groups, and their contents, are deleted and a new empty default execution group is created.
    2. Re-create the execution groups that were originally within the broker. Re-create only the execution groups that you want to preserve. Use the information that you recorded previously for this purpose. For detailed instructions on how to perform this task, see Adding an execution group to a broker.
    3. For each execution group that was originally within the broker, prepare a broker archive (bar) file. The broker archive file must contain the following items:
      • The message flows that were originally assigned to the execution group
      • The message sets that were originally assigned to the broker.
      For each assigned message flow, set the following properties:
      • Additional instances
      • Commit count
      • Commit interval
      • Coordinated transaction.

      Re-create only the assignments configuration data that you want to preserve. Use the information that you recorded previously to prepare the broker archive file.

    4. When the broker archive file is ready, deploy it to the broker. For detailed instructions on how to perform this task, see Deploying.

      Deploy migrated message flows and message sets to a test environment first. When you are sure that they are working correctly, then deploy them to a production environment.

  12. On a system where the workbench runs, deploy the complete topology and topics configuration data. For detailed instructions on how to perform these tasks, see Deploying a publish/subscribe topology and Deploying a publish/subscribe topics hierarchy.
The migration is now complete and the broker domain is ready for use.
Drop any database tables or databases and delete any queue managers that you no longer require.

If you preserved the assignments, topology, and topics data in the configuration repository during the migration and did not delete the Configuration Manager, the Configuration Manager database tables after migration contain development data that the Configuration Manager no longer requires. When you are sure that the migration has been successful, delete this data. For information about how to do this, see Removing the Configuration Manager database tables after migration.

Related concepts
Conditions for a Version 2.1 broker participating in a Version 5.0 broker domain
Related tasks
Preparing to migrate from WebSphere MQ Integrator Broker Version 2.1
Installing on AIX
Installing on HP-UX
Installing on Solaris
Installing on Windows
Installing on z/OS
Creating a Configuration Manager on Windows
Starting and stopping the Configuration Manager
Creating a domain connection
Migrating a message flow
Migrating a message set
Creating a User Name Server on AIX
Creating a User Name Server on HP-UX
Creating a User Name Server on Solaris
Creating a User Name Server on Windows
Creating a User Name Server on z/OS
Starting and stopping the User Name Server on Linux and UNIX systems
Starting and stopping the User Name Server on Windows
Starting the User Name Server on z/OS
Changing the ODBC connection and XA resource manager definitions for a migrated broker
Configuring a migrated broker on z/OS
Starting and stopping a broker on Linux and UNIX systems
Starting and stopping a broker on Windows
Starting the broker
Adding an execution group to a broker
Deploying a publish/subscribe topology
Deploying a publish/subscribe topics hierarchy
Deploying
Removing the Configuration Manager database tables after migration
Issuing commands from a program after migration
Related reference
Supported migration and upgrade paths
Assignments configuration data in an export file
mqsistop command
mqsideletebroker command
mqsideleteusernameserver command
mqsimigratetables command
mqsicreateconfigmgr command
mqsistart command
mqsimigratemsgflows command
mqsimigratemsgsets command
mqsicreateusernameserver command