This topic applies only to the IBM Business Process Manager Advanced configuration.

This topic applies only to the IBM Business Process Manager Standard configuration.

Planning to migrate multiple deployment environments or extra clusters

If you are planning to migrate your business data and applications to IBM BPM V8.5.5 and you have more than one deployment environment in one cell in IBM® BPM Advanced or WebSphere® Process Server, or if you have a deployment environment and extra clusters, you must perform more steps.

Table 1. Migration sources and targets
If you are coming from...	...plan to map to
Two deployment environments in one cell	Two 3-cluster Process Server deployment environments
WebSphere Process Server deployment environment and WebSphere Enterprise Service Bus cluster or clusters	One 3-cluster deployment environment (Process Center or Process Server) and an extra single-cluster or 3-cluster Process Server deployment environment using the AdvancedOnly deployment type
WebSphere ESB 2-cluster topology	One 3-cluster Process Server deployment environment using the AdvancedOnly deployment type
WebSphere Process Server with two application target clusters that share a single messaging engine cluster	One 3-cluster deployment environment and another 3-cluster or single-cluster deployment environment. Messaging engine clusters can no longer be shared by multiple application target clusters. Map the first application cluster and the messaging engine cluster to a 3-cluster topology. Map the second application target cluster to another 3-cluster topology.
WebSphere Process Server deployment environment and WebSphere Application Server cluster	One 3-cluster deployment environment (Process Center or Process Server). Create an extra WebSphere Application Server cluster after migration and redeploy your WebSphere Application Server applications.

Two deployment environments in one cell

You have two full deployment environments that share common database tables. Your applications might include business process definitions (BPDs), Business Process Execution Language (BPEL) processes (both long-running processes and microflows), and Service Component Architecture (SCA) applications.

To migrate, complete the following additional steps:

For each deployment environment in your source, make a copy of the migration properties file that is used as input for most of the migration commands.
If you are migrating multiple deployment environments, you must use a different source migration properties file for each one where you assign values to the following parameters:
- source.application.cluster.name
- source.messaging.cluster.name
- source.support.cluster.name
- source.web.cluster.name
These cluster name parameters must have different values between deployment environments. However, within the same migration properties file, the values can be the same.
If you are migrating from a single cluster environment, enter a value for the application cluster name, for example:
- source.application.cluster.name=SingleCluster
- source.messaging.cluster.name=
- source.support.cluster.name=
- source.web.cluster.name=
If you are migrating from a network deployment environment, input the names of the clusters that exist in your source environment, for example:
- source.application.cluster.name=ApplicationCluster
- source.messaging.cluster.name=MessagingCluster
- source.support.cluster.name=SupportCluster
- source.web.cluster.name=
In addition, you must specify values for the following parameters in each file:
- admin.username
- admin.password
- bpm.home
- profile.name
For configuring multiple deployment environments:
- Run the BPMConfig -migrate command in each of your deployment environments to generate separate properties files. Modify your version of each properties file in the IBM BPM Configuration editor, editing the properties for user credentials, database information, hostname, and installation path.
- One of the new deployment environments can reuse the common database for both the cell-scoped and deployment-environment-scoped data, but you must create a new deployment-environment-scoped database for the extra deployment environment.
- Create two three-cluster deployment environments by running the BPMConfig -create command with each of the configuration files that you created.
- Make sure that the name of the authentication alias for each database is different if there is a different user name in each deployment environment. Otherwise, the creation of the second deployment environment will fail because the authentication alias uses a different user name.
  For example, your first deployment environment has the authentication alias BPM_DB_ALIAS with user1 as the user name.
```
bpm.de.authenticationAlias.3.name=BPM_DB_ALIAS
bpm.de.authenticationAlias.3.user=user1
bpm.de.authenticationAlias.3.password=
```
  Before you create the second deployment environment, check the BPMConfig properties file to make sure that the same authentication alias does not exist with a different user name. If so, change the name of the authentication alias. For example:
```
bpm.de.authenticationAlias.3.name=BPM_DB_ALIAS_2
bpm.de.authenticationAlias.3.user=user2
bpm.de.authenticationAlias.3.password=
```
Each time that the migration steps are for one deployment environment, you must repeat the steps for each deployment environment that you want to migrate.
You must empty the failed event tables before migrating. Resubmit or delete the failed events before migration. See the Application Scheduler information for instructions.
For the new deployment-environment-scoped database that you created for one of your deployment environments, you must export the data from the jdbc/WPSDB data source (JNDI) name in the source and import it into the event sequencing table (PERSISTENTLOCK) in the new database.

WebSphere Process Server deployment environment and WebSphere Enterprise Service Bus cluster or clusters

You have a WebSphere Process Server deployment environment and an extra WebSphere ESB deployment target that is used only to run mediations.

To migrate, complete the following additional steps:

For each deployment environment in your source, make a copy of the migration properties file that is used as input for most of the migration commands.
If you are migrating multiple deployment environments, you must use a different source migration properties file for each one where you assign values to the following parameters:
- source.application.cluster.name
- source.messaging.cluster.name
- source.support.cluster.name
- source.web.cluster.name
These cluster name parameters must have different values between deployment environments. However, within the same migration properties file, the values can be the same.
If you are migrating from a single cluster environment, enter a value for the application cluster name, for example:
- source.application.cluster.name=SingleCluster
- source.messaging.cluster.name=
- source.support.cluster.name=
- source.web.cluster.name=
If you are migrating from a network deployment environment, input the names of the clusters that exist in your source environment, for example:
- source.application.cluster.name=ApplicationCluster
- source.messaging.cluster.name=MessagingCluster
- source.support.cluster.name=SupportCluster
- source.web.cluster.name=
In addition, you must specify values for the following parameters in each file:
- admin.username
- admin.password
- bpm.home
- profile.name
When you reach the step where you configure IBM BPM:
- Run the BPMConfig -migrate command in each of your deployment environments to generate separate properties files. Modify your version of each properties file in the IBM BPM Configuration editor, editing the properties for user credentials, database information, hostname, and installation path.
- First, create a three-cluster deployment environment. Then, create a single-cluster or three-cluster AdvancedOnly Process Server deployment environment.
- Make sure that the name of the authentication alias for each database is different if there is a different user name in each deployment environment. Otherwise, the creation of the second deployment environment will fail because the authentication alias uses a different user name.
  For example, your first deployment environment has the authentication alias BPM_DB_ALIAS with user1 as the user name.
```
bpm.de.authenticationAlias.3.name=BPM_DB_ALIAS
bpm.de.authenticationAlias.3.user=user1
bpm.de.authenticationAlias.3.password=
```
  Before you create the second deployment environment, check the BPMConfig properties file to make sure that the same authentication alias does not exist with a different user name. If so, change the name of the authentication alias. For example:
```
bpm.de.authenticationAlias.3.name=BPM_DB_ALIAS_2
bpm.de.authenticationAlias.3.user=user2
bpm.de.authenticationAlias.3.password=
```
Each time that the migration steps are for one deployment environment, you must repeat the steps for each deployment environment that you want to migrate.

Deployment environment and WebSphere Application Server cluster

You have a deployment environment and an extra WebSphere Application Server cluster that is used to run WebSphere Application Server applications.

To migrate, complete the following additional steps:

Complete the migration to IBM BPM Advanced V8.5.5 following the normal steps to migrate your deployment environment.
Create a WebSphere Application Server cluster in the target environment and redeploy your WebSphere Application Server applications.
Make sure that the name of the authentication alias for each database is different if there is a different user name in each deployment environment. Otherwise, the creation of the second deployment environment will fail because the authentication alias uses a different user name.
For example, your first deployment environment has the authentication alias BPM_DB_ALIAS with user1 as the user name.
```
bpm.de.authenticationAlias.3.name=BPM_DB_ALIAS
bpm.de.authenticationAlias.3.user=user1
bpm.de.authenticationAlias.3.password=
```
Before you create the second deployment environment, check the BPMConfig properties file to make sure that the same authentication alias does not exist with a different user name. If so, change the name of the authentication alias. For example:
```
bpm.de.authenticationAlias.3.name=BPM_DB_ALIAS_2
bpm.de.authenticationAlias.3.user=user2
bpm.de.authenticationAlias.3.password=
```