IBM BPM, V8.0.1, All platforms > Migrating and upgrading your IBM BPM environment > Migrating from previous versions > Migrating your IBM BPM Advanced V7.5.x or WebSphere Process Server V7.x or V6.2.x runtime > Runtime migration procedures

Migrating an ND environment with minimal downtime

Use this procedure to migrate an ND environment while incurring minimal downtime. Choose this procedure only when the amount of downtime required for the migration directly impacts your business. The minimal downtime procedure is more complex than the full downtime procedure, and should be used only when the length of the downtime is critical.

Review the Migration overview and Runtime premigration checklist topics.

If the source version contains applications that exploit Business Calendars or mediation flow components, the minimum downtime procedure can be used only if those applications can tolerate some downtime. Nodes with servers that are running applications that exploit Business Calendars or mediation flow components will remain stopped until the node is migrated to the new version.


Procedure

Follow these steps to migrate an ND environment while incurring minimal downtime.

  1. Install the migration target product(s).

    Install the target product and the latest fix packs on the same system as the source product of the migration.

    You must either install the target version with the same user ID as that used for installing the source version, or have permission to access the configuration and data on the source installation.

    To migrate from source profiles augmented by multiple products, the new version of those products must be installed into the same target installation directory.

    For example, if the source profile is augmented by IBM BPM and IBM Business Monitor, both of those products must be installed into the same target installation directory.

  2. Upgrade DB2 for z/OS and OS/390 Version 7.

    If you use DB2 for z/OS and OS/390 Version 7, and have not yet upgraded the database to DB2 for z/OS Version 8 or DB2 9 for z/OS, perform the upgrade now, as described in the DB2 for z/OS documentation.

  3. Identify the clusters, clustered managed nodes, and non-clustered managed nodes to migrate.

    If you intend to migrate an entire cell, you will migrate:

    • The dmgr

    • All nodes that do not have an application server that is a member of any cluster in the cell (non-clustered managed nodes)

    • All clusters and all the nodes that have application servers that are members of those clusters (clustered managed nodes)

    If you are not migrating an entire cell, you do not intend to migrate any clusters, and you do intend to migrate one or more nodes that do not have an application server that is a member of any cluster in the cell (non-clustered managed nodes), you will migrate:

    • The dmgr
    • Each non-clustered managed node you intend to migrate

    If you are not migrating an entire cell, intend to migrate one or more clusters in the cell, and zero or more non-clustered managed nodes, you will migrate:

    • The dmgr.
    • Each non-clustered managed node you intend to migrate.
    • Each cluster you explicitly intend to migrate and all the nodes that have an application server that is a member of that cluster (clustered managed nodes).

    • Any cluster and that cluster's clustered managed nodes implicitly impacted by the clusters that you intend to migrate. To identify the transitive closure of all the impacted clusters and their clustered managed nodes, use the following procedure:

      • For each cluster you intend to migrate, identify all the clustered managed nodes that have application servers that contribute to the cluster.

      • For each clustered managed node, determine what other clusters, if any, the application servers running on the node are members of.
      • Repeat the process for each of these clusters to determine the complete set of clusters and clustered managed nodes that must be migrated as part of this procedure.

  4. Disable synchronization for all nodes.

    Disable synchronization for all non-clustered managed nodes and clustered managed nodes using the administrative console on the source dmgr.

    1. From the WebSphere Application Server administrative console, select System administration > Node agents.

    2. Click the node agent for the node.

    3. Click File synchronization service.
    4. Make a note of the following settings so they can be restored later in the procedure when you re-enable node synchronization:

      • Enable service at server startup

      • Automatic synchronization

      • Startup synchronization

    5. Clear the following options:

      • Enable service at server startup

      • Automatic migration

      • Startup synchronization

    6. Click Apply, then click OK to save the configuration changes and to make sure that all nodes in the cell are synchronized to make the changes effective on the node agents.
  5. Stop the dmgr.

    Stop the migration source's dmgr using the stopManager command from the profile_root/bin directory on the migration source system or from the First steps console for the profile.

    Use the following syntax:

    • stopManager.sh -username user_name -password password

    • stopManager.bat -username user_name -password password

    If the profile has security enabled, the user name provided must be a member of the operator or administrator role.

    If security is enabled, you do not have to specify the -username and -password parameters if the server is running as a Windows service. In this case, the parameters are automatically passed into the script that the Windows service uses to shut down the server.

    If the profile does not have security enabled, the -username and -password parameters are unnecessary.

    For more information about the stopManager command, see stopManager command in the WebSphere Application Server information center.

  6. Back up the source dmgr profile.

    Back up the dmgr profile configuration on the source dmgr system using the backupConfig command.

    Use the following syntax to back up a profile named dmgrProfile to /ProfileBackups/dmgrProfile.zip:

    • backupConfig.sh /ProfileBackups/dmgrProfile.zip -profileName dmgrProfile

    • backupConfig.bat c:\ProfileBackups\profile1.zip -profileName dmgrProfile

    For more information about the backupConfig command, see backupConfig command in the WebSphere Application Server information center.

  7. Back up the cell-scoped Common database.

    Back up the cell-scoped Common database using the documentation for your database server.

  8. Migrate the dmgr profile.

  9. Upgrade the cell-scoped Common database.

    • If you are migrating from WebSphere Process Server 6.2 or 7.0, upgrade the Common database schema following the instructions in Migrating the Common database.
    • If you are migrating from IBM BPM 7.5, it is not necessary to perform a schema upgrade for the Common database.

    Important: Do not upgrade the databases for Business Process Choreographer or Business Space, because they are configured at a cluster or server scope and should be updated only when the managed nodes have been migrated to V8.0.1, which happens later in Steps 17 and 34.

  10. Start the target dmgr.

    Start the target dmgr using the startManager command from the profile_root/bin directory on the dmgr system or from the First steps console for the dmgr profile.

    Use the following syntax:

    • startManager.sh

    • startManager.bat

    For more information about the startManager command, see startManager command in the WebSphere Application Server information center.

  11. Migrate the non-clustered managed nodes.

    Repeat steps 11 through 21 for each non-clustered managed node that is a source of the migration. If your setup does not include non-clustered managed nodes, skip this step and go to 22.

  12. Stop the non-clustered managed node migration source servers.

    Stop the migration source server using the stopServer command from the profile_root/bin directory on the migration source system or from the First steps console for the profile.

    Use the following syntax:

    • stopServer.sh server_name -username user_name -password password

    • stopServer.bat server_name -username user_name -password password

    If the profile has security enabled, the user name provided must be a member of the operator or administrator role.

    If security is enabled, you do not have to specify the -username and -password parameters if the server is running as a Windows service. In this case, the parameters are automatically passed into the script that the Windows service uses to shut down the server.

    If the profile does not have security enabled, the -username and -password parameters are unnecessary.

    For more information about the stopServer command, see stopServer command in the WebSphere Application Server information center.

  13. Stop the non-clustered managed node migration source node agent.

    Stop the migration source's node agent using the stopNode command from the profile_root/bin directory of the migration source system.

    Use the following syntax:

    • stopNode.sh -username user_name -password password

    • stopNode.bat -username user_name -password password

    If the profile has security enabled, the user name provided must be a member of the operator or administrator role.

    If security is enabled, you do not have to specify the -username and -password parameters if the server is running as a Windows service. In this case, the parameters are automatically passed into the script that the Windows service uses to shut down the system.

    If the profile does not have security enabled, the -username and -password parameters are unnecessary.

    For more information about the stopNode command, see stopNode command in the WebSphere Application Server information center.

  14. Back up the non-clustered managed node migration source profile.

    Back up the profile configuration on the non-clustered managed node using the backupConfig command.

    Use the following syntax to back up a profile named profile1 to /ProfileBackups/profile1.zip:

    • backupConfig.sh /ProfileBackups/profile1.zip -profileName profile1

    • backupConfig.bat c:\ProfileBackups\profile1.zip -profileName profile1

    For more information about the backupConfig command, see backupConfig command in the WebSphere Application Server information center.

  15. Back up the server-scoped product databases configured for the non-clustered managed node.

    Back up the following product databases that are configured for the non-clustered managed node according to the documentation for your database:

  16. Migrate the non-clustered managed node.

    Use the IBM BPM profile migration wizard or the IBM BPM migration command-line utilities to migrate the non-clustered managed node source profile.

  17. Upgrade the product databases for the non-clustered node. Upgrade only the databases for Business Process Choreographer and Business Space that are configured at the server scope under the non-clustered node that is being migrated.

  18. Migrate the instance data for Business Space if it is configured in the source environment. Perform the following step to update the data in the databases to work with V8.0.1.

  19. Enable synchronization for the non-clustered managed node.

    Enable synchronization for the non-clustered managed node that has been migrated using administrative console on the target dmgr.

    1. From the WebSphere Application Server administrative console, select System administration > Node agents.

    2. Click the node agent for the node.

    3. Click File synchronization service.
    4. Restore the settings for:

      • Enable service at server startup

      • Automatic synchronization

      • Startup synchronization

    5. Click Apply, then click OK to save the configuration changes and to make sure that all nodes in the cell are synchronized to make the changes effective on the node agents.

  20. Start the migration target non-clustered managed node agent.

    Start the node agent of the migration target non-clustered managed node using the startNode command from the profile_root/bin directory of the migration target server or from the First steps console for the profile.

    Use the following syntax:

    • startNode.sh

    • startNode.bat

    For more information about the startNode command, see startNode command in the WebSphere Application Server information center.

  21. Start the migration target non-clustered managed node server.

    Start the migration target non-clustered managed node target server using the startServer command from the profile_root/bin directory of the migration target server or from the First steps console for the profile.

    Use the following syntax:

    • startServer.sh server_name

    • startServer.bat server_name

    For more information about the startServer command, see startServer command in the WebSphere Application Server information center.

  22. Migrate the clusters.

    Repeat 22 through 42 for each cluster in the ND environment that needs to be migrated.

    Divide the nodes that contain servers that contribute to the cluster into two roughly equivalent sized groups, group A and group B. The group B nodes will continue to service consumer requests while the group A nodes are taken offline and migrated. When the group A nodes are migrated, all nodes will be stopped, the databases configured for the cluster will be migrated, and the migrated group A nodes will be started and can begin servicing consumer requests. The group B nodes will then be migrated and started. Staggering the migration over the two groups of nodes will minimize the amount of time the cluster will need to be down in order to migrate the product databases.

  23. Stop the group A clustered managed node migration source servers.

    Repeat this step for each server associated with a clustered managed node that will be migrated as part of group A.

    Stop the migration source server using the stopServer command from the profile_root/bin directory on the migration source system or from the First steps console for the profile.

    Use the following syntax:

    • stopServer.sh server_name -username user_name -password password

    • stopServer.bat server_name -username user_name -password password

    If the profile has security enabled, the user name provided must be a member of the operator or administrator role.

    If security is enabled, you do not have to specify the -username and -password parameters if the server is running as a Windows service. In this case, the parameters are automatically passed into the script that the Windows service uses to shut down the server.

    If the profile does not have security enabled, the -username and -password parameters are unnecessary.

    For more information about the stopServer command, see stopServer command in the WebSphere Application Server information center.

  24. Stop the group A clustered managed node migration source node agents.

    Repeat this step for each node agent associated with a clustered managed node that will be migrated as part of group A.

    Repeat this step for each node agent that is impacted by the migration.

    Stop the migration source's node agent using the stopNode command from the profile_root/bin directory of the migration source system.

    Use the following syntax:

    • stopNode.sh -username user_name -password password

    • stopNode.bat -username user_name -password password

    If the profile has security enabled, the user name provided must be a member of the operator or administrator role.

    If security is enabled, you do not have to specify the -username and -password parameters if the server is running as a Windows service. In this case, the parameters are automatically passed into the script that the Windows service uses to shut down the system.

    If the profile does not have security enabled, the -username and -password parameters are unnecessary.

    For more information about the stopNode command, see stopNode command in the WebSphere Application Server information center.

  25. Back up the group A migration source profiles.

    Repeat this step for each profile that will be migrated in group A.

    Back up the profile configuration on the non-clustered managed node using the backupConfig command.

    Use the following syntax to back up a profile named profile1 to /ProfileBackups/profile1.zip:

    • backupConfig.sh /ProfileBackups/profile1.zip -profileName profile1

    • backupConfig.bat c:\ProfileBackups\profile1.zip -profileName profile1

    For more information about the backupConfig command, see backupConfig command in the WebSphere Application Server information center.

  26. Migrate the group A managed nodes.

    This step should be repeated for each group A managed node in the cluster.

  27. Stop the group B clustered managed node migration source servers.

    Repeat this step for each server associated with a clustered managed node that will be migrated as part of group B.

    Stop the migration source server using the stopServer command from the profile_root/bin directory on the migration source system or from the First steps console for the profile.

    Use the following syntax:

    • stopServer.sh server_name -username user_name -password password

    • stopServer.bat server_name -username user_name -password password

    If the profile has security enabled, the user name provided must be a member of the operator or administrator role.

    If security is enabled, you do not have to specify the -username and -password parameters if the server is running as a Windows service. In this case, the parameters are automatically passed into the script that the Windows service uses to shut down the server.

    If the profile does not have security enabled, the -username and -password parameters are unnecessary.

    For more information about the stopServer command, see stopServer command in the WebSphere Application Server information center.

  28. Stop the group B clustered managed node migration source node agents.

    Repeat this step for each node agent associated with a clustered managed node that will be migrated as part of group B.

    Repeat this step for each node agent that is impacted by the migration.

    Stop the migration source's node agent using the stopNode command from the profile_root/bin directory of the migration source system.

    Use the following syntax:

    • stopNode.sh -username user_name -password password

    • stopNode.bat -username user_name -password password

    If the profile has security enabled, the user name provided must be a member of the operator or administrator role.

    If security is enabled, you do not have to specify the -username and -password parameters if the server is running as a Windows service. In this case, the parameters are automatically passed into the script that the Windows service uses to shut down the system.

    If the profile does not have security enabled, the -username and -password parameters are unnecessary.

    For more information about the stopNode command, see stopNode command in the WebSphere Application Server information center.

  29. Migrate the cluster.

    Migrate the cluster-scoped profile using the BPMMigrateCluster command from the target_INSTALL_ROOT/bin directory on the system containing the dmgr.

    Use the following syntax to migrate a cluster named applicationCluster1 with a dmgr profile named dmgrProfile copied in the /MigrationSnapshots/ProcServer directory:

    For more information about the BPMMigrateCluster command, see BPMMigrateCluster command-line utility.

  30. Enable synchronization for all clustered nodes.

    Enable synchronization for all nodes in the cluster (both group A and group B) using the administrative console on the target dmgr. Use the following procedure:

    1. From the WebSphere Application Server administrative console, select System administration > Node agents.

    2. Click the node agent for the node.

    3. Click File synchronization service.

    4. Select Enable service at server startup, Automatic synchronization and Startup synchronization.

    5. Click Apply, then click OK to save the configuration changes.
  31. Back up the group A migration target profiles.

    Repeat this step for each profile that will be migrated in group A. This backup is needed in case the next step for running the syncNode command fails. After resolving the issue with syncNode, you can restore the backup before running the syncNode command again.

    Back up the profile configuration on the non-clustered managed node using the backupConfig command.

    Use the following syntax to back up a profile named profile1 to /ProfileBackups/profile1.zip:

    • backupConfig.sh /ProfileBackups/profile1.zip -profileName profile1

    • backupConfig.bat c:\ProfileBackups\profile1.zip -profileName profile1

    For more information about the backupConfig command, see backupConfig command in the WebSphere Application Server information center.

  32. Synchronize all Group A nodes.

    Repeat this step for each group A clustered managed node in the cluster.

    Synchronize the node with the target dmgr using the syncNode command from the profile_root/bin directory of the migration target profile or from the First steps console of the target profile.

    Use the following syntax:

    • syncNode.sh deployment_manager_machine_name_or_ip_address deployment_manager_port_no

    • syncNode.bat deployment_manager_machine_name_or_ip_address deployment_manager_port_no

    For more information about the syncNode command, see syncNode command in the WebSphere Application Server information center.

  33. Back up the cluster-scoped product databases configured for the cluster.

    Back up the following product databases that are configured for the cluster according to the documentation for your database:

  34. Upgrade the product databases for the non-clustered node. Upgrade only the databases for Business Process Choreographer and Business Space that are configured at the server scope under the non-clustered node that is being migrated.

  35. If the source version is 7.5.x, update the Process Server and Performance Data Warehouse databases following the instructions in Upgrading existing databases, using the UpgradeProcessData command from the target_INSTALL_ROOT/BPM/Lombardi/tools/upgrade/UpgradeProcessData directory.

    For example:

  36. Migrate the instance data for Business Space if it is configured in the source environment. Perform the following step to update the data in the database to work with V8.0.1.

  37. Start the group A migration target node agent.

    Repeat this step for each group A clustered managed node in the cluster.

    Start the migration target node agent using the startNode command from the profile_root/bin directory of the migration target server or from the First steps console for the profile.

    Use the following syntax:

    • startNode.sh

    • startNode.bat

    For more information about the startNode command, see startNode command in the WebSphere Application Server information center.

  38. Start the group A migration target servers.

    Repeat this step for each server associated with a group A clustered managed node in the cluster.

    Start the migration target server using the startServer command from the profile_root/bin directory of the migration target server or from the First steps console for the profile.

    Use the following syntax:

    • startServer.sh server_name

    • startServer.bat server_name

    For more information about the startServer command, see startServer command in the WebSphere Application Server information center.

  39. Back up the group B migration source profiles.

    Repeat this step for each profile that will be migrated in group B.

    Back up the profile configuration on the non-clustered managed node using the backupConfig command.

    Use the following syntax to back up a profile named profile1 to /ProfileBackups/profile1.zip:

    • backupConfig.sh /ProfileBackups/profile1.zip -profileName profile1

    • backupConfig.bat c:\ProfileBackups\profile1.zip -profileName profile1

    For more information about the backupConfig command, see backupConfig command in the WebSphere Application Server information center.

  40. Migrate the group B managed nodes.

    This step should be repeated for each group B managed node in the cluster.

    It is not necessary to synchronize the Group B nodes as there is a syncNode execution at the end of the BPMMigrateProfile command.

  41. Start the group B migration target node agent.

    Repeat this step for each group B clustered managed node in the cluster.

    Start the migration target node agent using the startNode command from the profile_root/bin directory of the migration target server or from the First steps console for the profile.

    Use the following syntax:

    • startNode.sh

    • startNode.bat

    For more information about the startNode command, see startNode command in the WebSphere Application Server information center.

  42. Start the group B migration target servers.

    Repeat this step for each server associated with a group B clustered managed node in the cluster.

    Start the migration target server using the startServer command from the profile_root/bin directory of the migration target server or from the First steps console for the profile.

    Use the following syntax:

    • startServer.sh server_name

    • startServer.bat server_name

    For more information about the startServer command, see startServer command in the WebSphere Application Server information center.

  43. Configure the additional features for IBM BPM V8.0.1 (for example, Business Process Definitions), because these are not configured during the runtime migration procedure.

    1. If you are migrating from version 6.2 or 7.0, configure Process Server and Performance Data Warehouse using the procedure described in the section Configure the Process Server and Performance Data Warehouse.

    2. If you are migrating from version 7.5, configure Process Portal using the BPMConfigureProcessServer command from the dmgrProfile/bin directory. Use the following syntax:

      • BPMConfigureProcessServer.sh

      • BPMConfigureProcessServer.bat

  44. If you are using a three-cluster or four-cluster configuration, and you have not yet configured a routing server for Business Space:

    1. To ensure that requests for Process Portal are redirected to the correct cluster, complete the steps in Configure a proxy server for Process Portal.

    2. If you want users to be able to access Process Portal using HTTP rather than the Business Space default of HTTPS, complete the steps in Designating HTTP or HTTPS settings for Business Space.

      Restriction: Be aware that not all of the Process Portal functionality is available if you change the access settings to HTTP.

  45. Optionally configure Process Center to create process applications and use the features of version 8.0.1. Refer to Roadmap for install IBM BPM Advanced.

  46. Optional: Uninstall the source dmgr.

    Once the migration is complete, the migration source dmgr can be uninstalled.

  47. Remove Compatibility Mode.

    If you chose the compatibility option (which is the default), and if all your nodes are completely migrated to the target version, run the convertScriptCompatibility script from the target_INSTALL_ROOT/bin directory on the dmgr to remove compatibility.

    Use the following syntax:

    • convertScriptCompatibility.sh

    • convertScriptCompatibility.bat

    For more information about the convertScriptCompatibility command, see convertScriptCompatibility command in the WebSphere Application Server information center.


Results

The ND environment is migrated to the target version.


What to do next

Verify that the migration was successful. For instructions, see Verifying migration.

If you have an IBM Forms Server configured with your Business Space in the earlier releases, you must manually deploy the BSpaceForms.ear after the migration. Deploy the BSpaceForms.ear from the WASHome\installableApps\BusinessSpace directory to the application server.

Runtime migration procedures


Related tasks:
Plan the runtime migration
Migrating a profile using the profile migration wizard
Migrating a profile using the command-line utilities
Manually upgrading the product databases
Verifying migration
Configure a Process Server
Configure the Business Performance Data Warehouse component on a server or cluster
Configure the Process Server and Performance Data Warehouse


Related reference:
Runtime premigration checklist
BPMMigrateCluster command-line utility
BPMConfigureProcessServer
installBRManager command-line utility