Migrating a network deployment environment to the same version on new hardware with full downtime

Use this procedure to migrate a network deployment environment to the same version on new hardware, while incurring full downtime.

Follow these steps to migrate a network deployment environment while incurring full downtime.

1. Install the migration target product(s).

   Install the identical version and fix packs for the products on the target system as are installed on the source system.

   Important: 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.
   Important: 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® Business Process Manager and IBM Business Monitor, both of those products must be installed into the same target installation directory.
2. To prepare to stop all Java Virtual Machines (JVMs) in the cell, identify all clusters, node agents, non-clustered servers, and the deployment manager. For example, in the topology illustrated, you would need to stop the following.
   • The three clusters
   • The node agents for nodes one and two
   • The non-clustered server in node three
   • The deployment manager for the cell
   Figure 1. Example topology with three clusters across two nodes plus a third node for non-clustered servers

   
3. Stop the clusters, node agents, non-clustered servers, and deployment manager.
   1. Stop all cluster members.
   2. Stop all node agents.
   3. Stop all non-clustered servers.
   4. Stop the deployment manager.

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

      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.

4. Back up the migration source profiles and the migration source product databases.
   1. Back up the migration source profiles.

      Repeat this step for each profile that will be migrated, including the deployment manager, each non-clustered managed node, and each managed node.

      Back up the profile configuration on the migration source server 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.
   2. Back up the migration source product databases.

      Back up the following databases that are configured by any of the migration source profiles according to the documentation for your database:

      • Business Process Choreographer Database
      • Business Space database
      • Common database
      • Common Event Infrastructure Database
      • Messaging Engine Database
      • Performance Data Warehouse database
      • Process Server or Process Center database
5. Migrate the deployment manager profile. Perform the Migrating a profile to the same version on a remote system (new hardware) procedure.
6. Start the target deployment manager.

   Start the target deployment manager using the startManager command from the profile_root/bin directory on the deployment manager system or from the First steps console for the deployment manager 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.

7. Migrate the managed nodes by performing Migrating a profile to the same version on a remote system (new hardware) for all nodes that are federated under the deployment manager.
8. Synchronize the migration target custom profiles with the deployment manager profile. Synchronize all the clustered nodes that participate in the clusters migrated in previous steps to update the target cluster configuration.
   1. Secure the changes made up to this point by making a new back up of your managed profiles. Back up the profile configuration on the 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.
   2. Synchronize the managed nodes. Synchronize the node with the target deployment manager using the syncNode command from the profile_root/bin directory of the migration target profile or from the target profile's First steps console. 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.
   3. If the syncNode command did not complete successfully, perform the following actions.
      1. Resolve the issues reported by the syncNode command.
      2. If necessary, restore the managed profiles that you backed up before running the syncNode command.
      3. Run the syncNode command again.
9. Start the migrated custom profiles.

   Repeat this step for each clustered managed node for each cluster that was migrated.

   Start the migration target node agent using the startNode command from the profile_root/bin directory of the migration target server.

   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.

10. Start the clusters. To start the clusters in your deployment environment, Deployment_Environment_Name, in the preferred sequence, perform the following actions using the administrative console:
    1. Click Servers > Clusters > WebSphere application server clusters.
    2. If your topology includes a messaging cluster, click the cluster name (typically Deployment_Environment_Name.Messaging) then click Start.
    3. If your topology includes a support cluster, click the cluster name (typically Deployment_Environment_Name.Support) then click Start.
    4. If your topology includes a web cluster, click the cluster name (typically Deployment_Environment_Name.Web) then click Start.
    5. If your topology includes an application deployment target cluster, click the cluster name (typically Deployment_Environment_Name.AppTarget) then click Start.
11. Start the non-clustered servers. Using the administrative console, start each server by clicking Servers > Server Types > WebSphere application servers, then the name of the server, and Start.
12. Optional: Uninstall the source deployment manager.

    Once the migration is complete, the migration source deployment manager can be uninstalled.