Many large scale IBM BPM implementations run a separate UI application. Normally these applications show no problem until they are upgraded to a new version of IBM BPM. For a headless BPM application either two versions of UI application is to be maintained OR all in-flight instances need to be migrated from old production environment to new production environment. The later is more elegant if done properly and some strategies for the same will be discussed here.

The example application was built in IBM BPM v7.5.0 standard edition and later upgraded to 7.5.1 in the same infrastructure. Later a separate infrastructure was built for IBM BPM 8.5.1 advanced edition (although advanced features are not used for the project) and migrated the current application in all environments to the new system.
Also all in-flight instances were migrated from production to new system.
In the migration strategy considered here all fixes were done prior to final migration in production, such that the application can go live just after migration. Also it is considered that all in-flight instances will be migrated in the production environment.

Pre Migration Validations –

  • Whether all critical functionalities will be still working after migration? This is the most important consideration
  • Will Code Change be required to meet some changed standards? E.g. Some Rest API standards have changed in 8.x, such as Task API will only work with Human and AJAX services.
  • If Application has third party integrations, then whether the third party integration will work after the migration?
  • Is the Volume of BPMDB and PDWDB are too high? A high volume of data will slow down migration considerably. Therefore an archival strategy should be in place if not already present.
  • Is there any custom work schedule or time schedule? This schedules will not be available in the new system and needs to be recreated.
  • Will legacy items be removed during migration? In most cases a removal of legacy item will require retrospective changes in code to manage migration of in-flight instances
  • Are new variables being introduced during migration? This should be handled post migration by manually entering data for the migrated in-flight instances.
  • Is there any change in the workflow? This should be handled very carefully in case in-flight instances are being migrated. Possible orphan tokens should be identified and handled post migration.
  • Is Different Active Directory being used? It should made sure that all user groups and bindings should be replicated in the new environment.

Migration Strategy

There are two approaches to migration as shown –

Old Dev --------> New Dev
Old Test --------> New Test
Old Stage --------> New Stage
Old Prod --------> New Prod

In this the code and/or data (in-flight instances) can be migrated to a new environment. OR existing environments can be upgraded by scripts

Old Dev --------> New Dev
Old Test New Test
Old Stage New Stage
Old Prod New Prod

In this only code is migrated to a new environment

In approach #1 it must be made sure to keep all the environment default snapshots in sync. Also this is unsafe approach as chances of failure is high in production.
In approach #2 all environment default snapshot will be synced automatically. This is safer approach with very less chances of failure in production.

Practically it needs to be tailored as per project. Below is the tailored strategy used by sample Application –

Old Dev --------> New Dev
[data and codes] |
Old Test New Test
Old Stage --------> New Stage
[data] |
Old Prod --------> New Prod

Post Migration Fixes

  • tw_admin is no more a system user, so the best solution is to add tw_admin as system user, in case in-flight instances are being migrated. This can be done right after the application is migrated. In case this cannot be done due to other constraints then the following approaches may be taken –
    • Reassign all tasks from tw_admin to deadmin.
    • Manually run all tasks assigned to tw_admin.
  • Any event which store data in the WAS BPM profile will loose all data if the profile is not migrated. This can be easily mitigated by adding the data manually via Process Inspector and resuming the failed instance.
  • If the existing instances are planned to be migrated over to a newer snapshot that contains extra variable or additional steps, then after migration data must be provided manually and check for orphaned tokens must be conducted.

IBM STG application Deal Registration is considered as a practical example behind this document.

1 comment on"Headless BPM Migration Strategy v7.x to 8.x"

  1. Anupama Padmanabhan December 10, 2015

    Samarjit, this is an excellent go-to document for all applications that are planning migration of their BPM versions. You have very clearly explained what they need to be aware of and what corrective action can be taken to avoid common pitfalls.

Join The Discussion

Your email address will not be published. Required fields are marked *