...

Otherwise, you may need to duplicate the existing user directory date (tables with prefix of dir_ in the database) to the new server.

Migration of Process Instances

Before We Begin

Before attempting anything, always perform a backup in any (app or database) servers that you will be working on. This is so that there's always something to fallback on, just in case!

Here's the checklist that we would recommend before the migration.

1. The target server has the same app, same process(es), and have been tested to be working end to end (with all integrations, and plugins fitted in). This is so that discrepency in app/process design can be ruled out in case of any problem arised later on.
2. The target server has the same user management, so that the same user assigned, in current server, can be found in target server. This is so that problem that may arise when assigning an user can be ruled out.

What to Migrate?

1. Make a list of process instances that are still running.
2. Copy these data over to the target server.
   1. Form Data from the database
   2. File Upload from wflow/app_formuploads
3. Now that form data and its uploaded files are available in the target server, we can migrate process instances over to the target server.
4. Based on the list compiled in step 1, start new process instance in the new server using the same user with reference to the form record ID.
   

...

1. Image Added
   Figure 4: Process Instance View
   
   In Figure 4 above, there are 3 vital information we need, and use them to call JSON API in the target server by using JSON API#web/json/workflow/process/start/(*:processDefId). We will also need to copy any workflow variable data over to the new instance too. We can pass on var_* parameters to set the workflow variables' values accordingly.
   
   At this point of time, the new process instance would be waiting at its very first activity.
   
   IMPORTANT NOTE: If you have tools that run right at the start of the process flow, this may cause manipulation of form data state. Take note of potential changes that may occur and devise a way to preserve original data/state.
2. Once a new process instance is started, note down the process instance ID generated, and we will then need to make use of JSON API#web/json/monitoring/activity/start/(*:processId)/(*:activityDefId) to resume the activity where it supposed to be, in the original server.
   
   NOTE: Depending on how many pending activities that we may have in the specific process instance, we may need to make multiple calls to this JSON API. Take note that in the first of such call, we will need to set the "abortCurrent" parameter value to "true" so that it aborts the first default pending activity instance. Subsequently, set "abortCurrent" parameter to "false".