Migrating a workflow in progress transfers responsibility for cases that have already performed some actions and still owe others. The task combines process-definition change, runtime-state mapping, and preservation of business authority. Importing a model or deploying a new version does not settle those responsibilities.

New requests can start under a replacement definition while old requests finish elsewhere. Moving active instances is another option, with different prerequisites. Each existing case needs one accountable continuation path.

Inventory state beyond the current label

A case marked pending can contain completed approvals, active tasks, timers, variables, incidents, and an outstanding response from an external worker. Those details determine what may happen next.

Record deployed definitions and versions alongside active instances. Include human assignments, correlation identifiers, integrations, and the side effects already completed. A count of open cases does not establish the state needed to resume them.

The migration population should distinguish cases ready to move from those requiring special handling. An unresolved incident can be more important to continuity than a large population of cases waiting at an uncomplicated stage.

Similar approval names can hide different rules

Power Automate distinguishes first-response approval from everyone-must-approve. The former completes on any assigned approver’s decision; the latter completes when everyone approves or one person rejects.

A replacement configured to wait for every rejection response would therefore implement a different rule from that documented example. Matching the label on a diagram does not establish matching completion semantics.

The business mapping should specify permitted actors, delegation, rejection, absence, changed requests, and escalation. These rules need confirmation for the actual process rather than being inferred from a platform’s default template.

Runtime migration has its own restrictions

Camunda 8.9 documents mappings for all active elements when moving an instance to another process definition. Its migration is transactional: a rejected migration leaves the instance in its previous state.

The documented operation also has wait-state and element-mapping restrictions, including constraints on element types and subprocess nesting. These are rules for that engine and version, not a general guarantee of BPMN portability or cross-engine migration.

A successful definition deployment thus establishes a narrower fact than accepted migration of active instances. The local rehearsal must exercise the actual states and destination mappings that production work requires.

Completed external actions must stay completed

Take a constructed case that has sent a payment instruction and is waiting for a response. Recreating the case at an earlier step can send the instruction again. Moving only a status field can instead lose the pending response or its correlation.

The continuation plan needs to preserve the identity and outcome of the external action. If the old and new workers coexist, ownership must prevent both from acting independently on the same obligation.

A rejected state migration can leave engine state intact while external transition work still needs coordination. Engine transactionality does not automatically encompass every surrounding service or manual step.

Rehearse representative waiting states

Test cases waiting for human action, timers, an external response, and incident resolution. Include rejection, withdrawal, absent approvers, and duplicate submission as well as successful approval.

Reconcile migrated, retained, completed, and manually resolved populations, with a reason for every exception. Historical access also needs a destination so that a future operator can explain decisions made before the transition.

A SaaS purchase can change where the workflow runs while leaving this mapping work intact. Acceptance requires each case to continue under the intended authority, preserve its completed effects, and reach an explainable result without duplicating outstanding actions.