Biggest difficulty of the migration projects is dealing with the live instances. Because in most cases customers doesn’t want to work in two environments till the on-prem instances finish.

If this is the case, IBM doesn’t have OOB application which is used for instance migration from one IBM BPM environment(on-prem) to another IBM BPM environment (on-cloud).

For this purpose I created a JAVA application which is getting all the data from on-prem environment and start a new process with these data in on-cloud then update the variables and moves the token to the correct step.

You can find details about the integration below.

Prerequisites

• We need to copy process applications from on prem to on cloud (Export/Import). This is very important because we are using flow object Id’s in the migration tool
• We need to add human task to beginning of the all processes in on cloud
• Check Timers UCA etc. If they are risky, remove these events
• Check connection from one environment to another

Original Version of Application

• This is the original version of the process.

Migration Version of Application

• This is the migration version of the process. We deploy this version to on-cloud and start this process during the migration. We are doing this because we don’t want to execute any system task when we start the process or move the token

Components of Data Migration Tool

• Java Integration
• TWX running on On Prem BPM Environment
• Table located in DB2 On Cloud

Algorithm of Java Integration

• Get Current Status of on-Prem Instance
• Get Visual Process Model of Instance. We need to differentiate parameters. Which one is input which one is private?
• Start Process in BPM On Cloud with input parameters
• Update private variables for main instance
• Move token & Suspend Instance

Variables

• Variables of the process application.

Move Token

• We need to get Instance Token Hierarchy
• First we extract execution tree from on-prem instance current status
• In this execution tree we are excluding all the event sub-processes
• If it is only main process, we can move token directly to any step.
• But if the main process has Linked Processes inside we cannot move the token directly inside the Linked Process. So first we need to move token to Linked Process’s start activity then we are able to move token inside the Linked Process
• If it has Linked Process inside Linked Process, we need to move the token in a loop.

Execution Tree of Linked Process

• Execution tree of the process. We can see the execution level clearly in this view.

Instance Child Tree

• Instance child tree which is extracted from current state of on-prem instance.

Converting the instance child tree to Process Hierarchy

• After we process the child tree, we get the hierarchy below which is saying us that we need to move the token 3 times.

Note: If our process doesn’t have Linked processes, we will have only one element in the array. This means we do move token only once.

Update private variables of Linked Process

• We need to update private variables in every single Linked Process. We cannot use Update variables rest api. But we can use the api below

Multi-Instance Loop (***I advice you to NOT to migrate this***)

• In multi instance loops we cannot update Linked Process private variables according to loop index. Last update overrides all indexes
• We cannot control which steps are closed already. We can lose data integrity

Evidence of Migration

• Migrate service is returning current status and instance id for both on-prem and on-cloud instance. In my case all these data was stored in DB2 on Cloud.

Note: If you store on-prem current state data in DB2, you can execute JAVA integration again without calling any service from on-prem BPM environment.

TWX running on On Prem BPM Environment

• This dashboard is providing the data to JAVA integration. This could run on on-prem, on-cloud and also outside of the BPM environments. It is only matter of connectivity.

UI for Migration

• This UI is only getting the list of instance Id’s and details about the process which we want to start.

After Migration

• After migration all the instances status will be suspended. We can check/control before resume them
• After checking them, if everything is fine then we can resume them.
• We need to migrate all the instances to the real version (the version without “Migrate — Inline User Task Step”)

Note: I advice you to create specific snapshot for migrated instances(the version without “Migrate — Inline User Task Step”). New instances can start from fresh snapshot and migrated ones can live on migrated snapshot. So you can isolate all the migrated instances from the new ones. If you do that design, you can re-migrate the instance any time if you see any error in the migrated instance.