Rolling back a deployment cell

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 subprocedures > Rolling back your environment
Rolling back a deployment cell

You can use the restoreConfig and wsadmin commands to roll back a migrated IBM BPM V8.0.1 deployment cell to an earlier version. This returns the configuration to the state that it was in before migration. After rolling back the deployment cell, you can restart the migration process.

When you migrate a deployment cell, you must perform all of the following backup steps in sequence to successfully complete the rollback.

Back up the databases that support IBM BPM components.
If the purpose of the rollback is to fix a problem that occurred during migration and rerun profile migration, do not perform a database rollback. Databases should be rolled back only if you need to start the managed node servers once they have been restored to the previous version.
Roll back the deployment target-scoped database, if applicable. Check whether the managed node has a server with Business Process Choreographer or Business Space components configured.

If the managed node does not have these components configured on any of the servers, go to Step 2.
If the managed node contains a server-scoped configuration for Business Process Choreographer or Business Space, roll back the database.
If the managed node has a server that is a member of a cluster where Business Process Choreographer and Business Space are configured, verify that rolling back the managed node would not result in a mixed-version cluster, with some cluster members on V8.0.1 and some on a previous version. A database rollback would cause cluster members on V8.0.1 to fail. Databases should be rolled back only if you decide to roll back all the managed nodes that participate in the cluster, and you plan to run the cluster on the previous version.

Back up your existing configuration using the backupConfig command or your own preferred backup utility.

Run the backupConfig command or your own preferred utility to back up the earlier version of the dmgr configuration.
Important: Make sure to note the exact name and location of this backed-up configuration.
See backupConfig command in the WebSphere Application Server information center.

Migrate the deployment cell.

Procedure
Stop all of the servers that are currently running in the IBM BPM V8.0.1 environment.
If you chose to disable the previous dmgr when you migrated to the V8.0.1 dmgr, take one of the following actions:
If you backed up your previous dmgr configuration using the backupConfig command or your own preferred backup utility, run the restoreConfig command or your own preferred utility to restore the earlier version configuration for the dmgr.
Important: Make sure that you restore the same backed-up configuration created just before you migrated the dmgr.
See restoreConfig command in the WebSphere Application Server information center.
If you did not back up your previous dmgr configuration, use the wsadmin command to run the migrationDisablementReversal.jacl script from the profile_root/bin directory of the earlier version of the dmgr.
In a Linux environment, for example, use the following parameters:
./wsadmin.sh -f migrationDisablementReversal.jacl -conntype NONE
If you have trouble running the migrationDisablementReversal.jacl script, try to go through the steps in the script manually.
Go to the following directory:
 profile_root/config/cells/ cell_name/nodes/ node_name
where node_name is the name of the dmgr node that you want to roll back.
If you see a serverindex.xml_disabled file in this directory, take the following actions:

Delete or rename the serverindex.xml file.
Rename the serverindex.xml_disabled file to serverindex.xml.
If you did not back up your previous dmgr configuration, use the wsadmin command to run the migrationDisablementReversal.jacl script from the Version 6.0.x WAS_HOME/bin directory of the dmgr.
Use the following parameters:
./wsadmin.sh -f migrationDisablementReversal.jacl -conntype NONE
If you have trouble running the migrationDisablementReversal.jacl script, try to go through the steps in the script manually.
Go to the following directory:
WAS_HOME/config/cells/ cell_name/nodes/ node_name
where node_name is the name of the dmgr node that you want to roll back.
If you see a serverindex.xml_disabled file in this directory, take the following actions:

Delete or rename the serverindex.xml file.
Rename the serverindex.xml_disabled file to serverindex.xml.
For each of the deployment cell's managed nodes that you need to roll back, take one of the following actions:
If you backed up your previous managed node configuration using the backupConfig command or your own preferred backup utility, run the restoreConfig command or your own preferred utility to restore the earlier configuration for the managed node.
Important: Verify that you restore the same backed-up configuration created just before you migrated the managed node.
See restoreConfig command in the WebSphere Application Server information center.
If you did not back up your previous managed node configuration, use the wsadmin command to run the migrationDisablementReversal.jacl script from the earlier version profile_root/bin directory of the managed node.
In a Linux environment, for example, use the following parameters:
./wsadmin.sh -f migrationDisablementReversal.jacl -conntype NONE
If you have trouble running the migrationDisablementReversal.jacl script, try to go through the steps in the script manually.
Go to the following directory:
 profile_root/config/cells/ cell_name/nodes/ node_name
where node_name is the name of the managed node that you want to roll back.
If you see a serverindex.xml_disabled file in this directory, take the following actions:

Delete or rename the serverindex.xml file.
Rename the serverindex.xml_disabled file to serverindex.xml.
If you did not back up your previous managed node configuration, use the wsadmin command to run the migrationDisablementReversal.jacl script from the earlier version INSTALL_ROOT/bin directory of the managed node.
Use the following parameters:
./wsadmin.sh -f migrationDisablementReversal.jacl -conntype NONE
If you have trouble running the migrationDisablementReversal.jacl script, try to go through the steps in the script manually.
Go to the following directory:
 INSTALL_ROOT/config/cells/ cell_name/nodes/ node_name
where node_name is the name of the managed node that you want to roll back.
If you see a serverindex.xml_disabled file in this directory, take the following actions:

Delete or rename the serverindex.xml file.
Rename the serverindex.xml_disabled file to serverindex.xml.
Synchronize the managed nodes if they were ever running when the V8.0.1 dmgr was running.
See syncNode command in the WebSphere Application Server information center.
If you chose to keep the installed applications in the same location as the prior release during migration to V8.0.1 and any of the V8.0.1 applications are not compatible with the prior release, install applications that are compatible.
Delete the V8.0.1 profiles.
See Delete profiles in the WebSphere Application Server information center.
Roll back your databases. (For any databases that support IBM BPM components that were upgraded, either automatically with the migration tools or manually, restore the backups made before you started the migration process.)
Start the rolled-back dmgr and its managed nodes in the earlier version environment.
Enable synchronization for all the nodes if it was disabled when you were following the steps in Migrating an ND environment with minimal downtime.Enable synchronization for all the nodes if it was disabled previously.
To do this, use the following procedure.

From the WebSphere Application Server administrative console, select System administration > Node agents.
Click the node agent for the node.
Click File synchronization service.
Select Enable service at server startup, Automatic synchronization and Startup synchronization.
Click Apply, then click OK to save the configuration changes.
Results
The configuration should now be returned to the state that it was in before migration.

What to do next
You can now restart the migration process if you want to do so.

Rolling back your environment