Assisted case and process migration

What it is

Assisted Migration is a new capability in Flowable Hub that guides operators through moving running process and case instances including their child processes and cases from one model version to the next. Rather than executing migrations blind, Hub first analyzes the live cohort, surfaces exactly what would change, and helps the operator build a safe, validated migration plan before anything is executed.

What’s included:

• Hierarchy-aware migration that moves a parent instance and all of its child scopes (call activities, process tasks, case tasks, sub-processes, sub-cases) in one coordinated execution, children first then parent
• Pre-flight cohort analysis for both BPMN process instances and CMMN case instances
• Filtered targeting by business key, start date range, and variable values with a live instance count
• Drill-down into the children of selected parent instances, so call activities, process tasks, and case tasks are migrated alongside their parents
• Side-by-side diff of source and target models showing active elements, missing elements that need mapping, and new elements in the target
• Visibility of every cross-definition reference in the hierarchy with the instances it affects
• Element mapping UI for resolving missing source elements against the target, including repetition handling for cases and per-user-task property overrides
• Dedicated sub-process and sub-case migration views to handle nested scopes in the same flow

Why it matters

Version migrations are one of the highest-risk operational tasks on a long-running platform. Assisted Migration turns the full instance hierarchy into the unit of work, so operators can confidently roll out new versions across thousands of running instances. Before executing anything, the team sees what is actually running across parents and children, which elements need mapping, and which child scopes will be touched. Mappings are made with full visibility, and the change is applied as a single coordinated plan with live progress. The result is faster, safer releases with no orphaned child scopes left on old versions.

How it works

1. The operator opens a definition in Hub and chooses a target version.
2. Hub asks for the scope: a single instance, a filtered cohort, or a set of parent instances whose hierarchies should be migrated.
3. A pre-flight count confirms how many instances are in the cohort.
4. Hub starts the analysis in the background, walking the running instances of the source version and every child scope they own. It builds up a picture of which elements are active across the hierarchy, which child definitions are involved, and how the cohort relates to the target model. Progress is shown live and the run can be cancelled or resumed at any time.
5. When the scan completes, Hub presents a structured result: active elements, missing elements, new elements, and every cross-definition reference in the hierarchy with the instances it touches.
6. The operator reviews the diff, maps missing elements to target elements, sets per-task overrides where needed, and steps through the child scopes one by one to resolve them.
7. The execute step applies the migration to the parent and all of its children in one coordinated operation, children first then parent, with a live progress indicator.
8. The full analysis is stored in Hub’s history for later reference or re-run.

Example

A bank runs a Loan Approval process. Version 1 has been live for a year with around 4,000 open instances. Each loan also spawns a Notification call activity and, for high-value loans, a Compliance sub-case. The team has just published version 2 of all three definitions: Loan Approval renames the Risk Assessment user task and adds a new Compliance Review step, Notification is restructured as a sub-process, and the Compliance sub-case picks up new evidence requirements.

The operator opens Loan Approval in Hub, picks version 2 as the target, and filters the cohort to instances started after January 1st. Hub reports 3,812 matching parent instances and starts the analysis across the full hierarchy. A few minutes later the result appears:

• Active in source: Risk Assessment (1,204 instances), Notification (2,108 instances), Approval Decision (500 instances)
• Missing in target: Risk Assessment, Notification
• New in target: Risk Review, Compliance Review, Notification sub-process
• Children in scope: 2,108 Notification call activities, 612 Compliance sub-cases, all listed with their parents

The operator maps Risk Assessment to Risk Review, steps through the Notification and Compliance sub-case views to confirm mappings for the children, and verifies that Compliance Review will be activated as a new step. They review the plan, execute the migration, and the parent processes together with all of their children move to version 2 in one coordinated operation, leaving no instance behind on an old version.