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, you must 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 Coexistence with previous releases and other products.

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

  1. Using a Control Center session, delete all brokers that you no longer require 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, do one of the following 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 the Version 2.1 level of code to the Version 5.0 level, stop the broker but do not delete it.
    • If you want to preserve the broker at the Version 2.1 level of code, do nothing. You do not have to stop it.

    On a UNIX or Windows system, you stop a broker by issuing the mqsistop command with the name of the broker, and you delete a 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 -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, you stop a User Name Server by issuing the mqsistop command for the component UserNameServer, and you delete a 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 you want to preserve at the Version 2.1 level of code, uninstall WebSphere MQ Integrator Broker. Follow the instructions in the appropriate book for your platform:
    • 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 you want to preserve at the Version 2.1 level of code, 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. Start of changeOptional: 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.End of change
    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.
    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, do the following:
    1. Start the workbench and connect the workbench 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 you are preserving at the Version 2.1 level of code and those you are migrating from the Version 2.1 level of code to the Version 5.0 level. 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 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 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, do the following:
    1. Create the User Name Server by issuing the mqsicreateusernameserver command. On z/OS, you must also 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, you 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 the Version 2.1 level of code to the Version 5.0 level, do the following:
    1. On a UNIX or Windows system, change the ODBC connection definition for each Oracle and Sybase database accessed by a broker. On AIX, also change the ODBC connection definition for each DB2 database accessed by a broker. Additionally, if a message flow running in a broker updates an Oracle or Sybase database within a global unit of work 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, you need to migrate the database tables only once. On z/OS, configure each broker. Configuring a broker includes migrating its database tables.
    3. Start of changeCreate new queues required by migrated brokers. On a UNIX or Windows system, create the queues by issuing the mqsimigratequeues command. On z/OS, as you configured the broker during the previous step, you have already created the new queues.
      For detailed instructions on how to perform these tasks, see:
      End of change
    4. Start each broker. On a UNIX or Windows system, you do this by issuing the mqsistart command with the name of the broker and, on z/OS, by starting the broker task. For detailed instructions on how to perform this task, see:
    You do not have to do anything for the brokers that you are preserving at the Version 2.1 level of code.
  11. On a system where the workbench runs, do the following for each broker that you are migrating from the Version 2.1 level of code to the Version 5.0 level:
    1. In the Domains view of the Broker Administration perspective, right-click the name of the broker and then click Remove Deployed Children. All the broker's execution groups, and their contents, are deleted and a new empty default execution group is created.
    2. Recreate the execution groups that were originally within the broker. Recreate only the execution groups you want to preserve. Use the information 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:
      • 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

      Recreate only the assignments configuration data you want to preserve. Use the information 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 message flow applications.

      Deploy migrated message flows and message sets to a test environment first of all. When you are sure that they are working correctly, you can 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 topology configuration and Deploying a topics hierarchy.
The migration is now complete and the broker domain is ready for use.
You can drop any database tables or databases, and delete any queue managers, 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, you can delete this data. For information about how to do this, see Cleaning up the Configuration Manager database tables after migration.

Related concepts
Coexistence with previous releases and other products
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
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 UNIX platforms
Starting and stopping the User Name Server on Windows
Starting and stopping a broker on UNIX platforms
Starting and stopping a broker on Windows
Deploying message flow applications
Cleaning up the Configuration Manager database tables after migration
Starting the User Name Server on z/OS
Starting the broker
Adding an execution group to a broker
Deploying a topology configuration
Deploying a topics hierarchy
Issuing commands from a program after migration
Changing the ODBC connection and XA resource manager definitions for a migrated broker
Configuring a migrated broker on z/OS
Related reference
Assignments configuration data in an export file
mqsicreateconfigmgr command
mqsicreateusernameserver command
mqsimigratemsgflows command
mqsimigratemsgsets command
mqsimigratetables command
mqsistart command
Supported migration and upgrade paths