Decide which open requests keep their original rules, which can move safely, and which must wait for an explicit exception decision.
Publishing a revised workflow does not answer what should happen to work already in progress. One request may be waiting for approval, another may have completed a step that no longer exists, and a third may be waiting for an external service to confirm an action. Treating all three as “open” hides the decisions that make a cutover safe.
In-flight workflow migration moves an existing process instance to a different process definition. This blueprint is for an operations owner coordinating an authorized change with a system operator. It is not a platform-to-platform data migration guide or permission to change policy retrospectively.
Separate the release decision from the running-work decision
A definition describes the workflow; an instance is one running execution; the business record holds the request, evidence and decisions. Keep those identities connected without assuming that changing one changes all three. A revised approval diagram does not establish that an earlier approval reviewed newly required evidence.
Operaton’s process-versioning documentation, for example, describes running instances continuing on their original version while new instances use the new version unless specified otherwise. That is documented behavior for that engine, not a universal promise about every workflow platform.
Use the broader change control process to authorize the release. Then create a separate disposition for affected running work. For AI-specific configuration and evaluation changes, the AI workflow version-control guide addresses a different layer of release governance.
Define the cutover boundary and decision rights
The trigger is an approved definition change with an intended effective boundary. Intake must identify the change owner, source and target definitions, affected request types, intended start time and time zone, reason, policy constraints and known external dependencies. If any of these are missing, the change coordinator owns clarification before a migration cohort is selected.
- Process owner: decides which business rules may apply to existing requests and approves exceptions within their authority.
- System operator: validates supported mappings, executes the authorized operation and reconciles its outcome.
- Request/task owner: confirms the evidence and accepts responsibility for the next action.
- Downstream owner: confirms the disposition of already-sent messages, bookings, payments or other external effects.
- Change coordinator: maintains the affected-work register, unresolved items and acceptance record.
Set the boundary using an authoritative event, such as accepted submission time, rather than when someone opens a notification. Define how returned-for-correction requests and substantial amendments are treated. Do not invent a new submission solely to make old work appear eligible.
Choose a treatment for each running state
Build the register from authoritative records, not a remembered list of pending work. Capture request and instance IDs, current definition, active tasks and owners, evidence revision, child instances, timers or deadlines, external-operation references and the observation time. Record how complete the inventory is.
| Observed condition | Treatment to decide | Evidence needed before proceeding |
|---|---|---|
| Original rules remain acceptable; authorized owners can finish | Continue under the original definition | Explicit eligibility, available owner and supported old-version operation |
| Active tasks and inputs map to the approved new path | Migrate through supported controls | Approved source-to-target mapping, complete new inputs and tested future route |
| New mandatory evidence is missing | Hold for evidence review | Named collection owner; verified evidence and authorization to resume |
| Request has passed a newly added review stage | Process owner decides whether additional review is required | Documented treatment of earlier decisions; an explicit supported route |
| External action is complete or its outcome is unknown | Reconcile before any state change that could repeat it | Actual downstream result and accepted next action |
| Policy forbids continuing and migration is unsupported | Hold for an authorized alternative | Approved linked correction, withdrawal or other business disposition; preserved history |
“Continue” is an active decision, not neglect. Give each retained cohort an owner, a review point and a rule for handling unavailable old-version dependencies. “Migrate” is not a label change: verify what happens to active tasks, required inputs and the next decision.
Model migration as work with its own states
Keep migration status separate from the request’s service status. A request awaiting approval can also be awaiting migration review; hiding one behind the other makes ownership ambiguous.
| Migration state | Accountable owner | Exit condition and retained evidence |
|---|---|---|
| Identified | Change coordinator | Instance, source version and current work are verified; scope accepted |
| Assessed | Process owner | Continue, migrate or hold decision recorded with reason and authority |
| Ready | System operator | Mapping, inputs, tests, owner acceptance and concurrent-action control pass |
| Reconciling | System operator | Original operation outcome and resulting tasks are established |
| Accepted | Receiving task owner | Correct version, current task, evidence, permissions and next route confirmed |
| Held | Named exception owner | Failed check resolved and evidence reviewed before returning to the appropriate state |
Camunda’s migration documentation requires mappings for active elements and describes rejection when a required mapping is missing. Use that as a reason to check the selected engine’s constraints. Matching task names alone does not prove matching behavior.
Handoff into execution
Sender: change coordinator. Completion condition: the process owner has approved the exact cohort and treatment. Context: instance list, observed states, source/target versions, mapping, input requirements, tests, stop conditions and exception owners. Receiver: system operator. Acceptance: the operator confirms supported execution, access and a current-state check. Rejected or incomplete packets return with a named correction owner.
Handoff back to operations
Sender: system operator. Completion condition: outcome is known and resulting tasks have been inspected. Context: operation reference, before/after state, actual version, remaining tasks, deadlines and exceptions. Receiver: the next task owner. Acceptance: that owner can access the evidence and perform the authorized next action. An operation marked successful is not sufficient business acceptance.
Design the stop and recovery paths
- Approval arrives during cutover: the operator checks the authoritative task and operation records. Hold conflicting outcomes; the system owner resolves the race. Resume only after one valid next state is established. Agree and test a pause or guarded-transition mechanism before execution; do not assume the platform provides one.
- Migration response times out: remain Reconciling. Inspect the original instance and operation through supported controls before retrying. Do not restart the business request or submit a second operation blindly.
- Owner unavailable or permissions fail: hold with the authorized backup and access-support owner. Resume after the receiver accepts and demonstrates needed access, not after informal permission expansion.
- Approval rejected or new evidence invalid: use the actual correction or rejection route. The process owner decides treatment; a migration must not convert a rejection into consent.
- Parallel branch or child still active: inventory every active component and confirm its mapping or separate disposition. Keep the cohort Held if one component is unresolved.
- Duplicate or conflicting migration instruction: link it to the original operation. The coordinator obtains one controlling decision; the operator reconciles actual state before acting.
- External dependency unavailable: the downstream owner verifies whether anything already happened. Resume only with a known result or an explicitly authorized containment path.
Flowable’s migration guide warns that migration has no automatic undo. More broadly, restoring a prior definition should not be treated as reversing a completed external action. Define which changes are technically reversible and which require separate business remediation.
Walk through a service-request cutover
Illustrative example: a service operation adds a site-readiness review before dispatch. The new definition applies to requests accepted after an agreed boundary. The process owner separately reviews existing work.
Request A has not reached dispatch and has complete readiness evidence. The operator verifies the supported mapping to readiness review, checks the next route and hands the review to its authorized owner. Acceptance includes opening the actual evidence, not merely seeing the new status.
Request B is already dispatched. Moving its diagram backward would not recall the field team. The downstream owner checks the actual assignment and customer commitment. The process owner records whether a separate readiness check or other authorized action is needed.
Request C has a pending approval that completes during the migration window. The operator stops its migration path, inspects the actual approval outcome and reconciles the current task before choosing the next action. C remains visible as unresolved until that evidence exists.
Accept the cohort and measure what remains
Before expanding a cutover, rehearse a request before the new gate, one past it, a returned request, missing evidence, an unavailable owner, a parallel branch, a simultaneous approval and a timed-out operation. Record expected and observed outcomes. Test representative states, not just fresh submissions.
- Demand: affected instances by source version and active state; distinguish newly identified work from repeat instructions.
- Flow: time from identification to accepted treatment, including held time.
- Queue health: oldest Held and Reconciling items, grouped by owner and failed check.
- Quality: accepted migrations later requiring task or evidence correction.
- Reliability: unknown outcomes, stale-task attempts and duplicate external actions detected.
- Capacity: ready items arriving versus operator reviews and receiving-owner acceptances completed.
- Outcome: sampled requests reaching the authorized next decision with preserved identity and evidence.
Reconcile the selected cohort into continued, migrated-and-accepted, held and other explicitly approved dispositions. Do not drop errors from the denominator or reset the original request age at migration. Review recurring failures with the process owner to improve the specific mapping, intake field or ownership rule.
Where Workhint fits
The Workhint Workflow Engine describes approval routing by role, required details or files before progression, and adjustments to workflow rules. Workhint’s Workflow Automation Software page describes forms, process stages, roles, conditional routing, tasks and event-based notifications. These building blocks are relevant to managing cutover intake, review and operational follow-up.
Those pages do not establish native running-instance migration, atomic handling of simultaneous actions, immutable snapshots or automatic undo. Validate those requirements in the proposed configuration and underlying engine. If a critical control is unavailable, retain a controlled manual gate or do not execute the migration.
Build This in Workhint
Configuration brief: “Coordinate an authorized cutover for [workflow]. Outcome: every affected running request has an accepted treatment and valid next owner. Define coordinator, process-owner, system-operator, receiving-owner and downstream-owner roles with limited permissions. Intake source/target versions, boundary, instance IDs, current tasks, evidence, deadlines, dependencies and external references. Track Identified, Assessed, Ready, Reconciling, Accepted and Held separately from service status. Require approved eligibility, mapping, complete evidence and accepted handoffs. Assign clarification, execution, reconciliation and exception tasks; notify owners at meaningful state changes. Retain actors, times, decisions and before/after evidence; validate history and audit behavior. Provide cohort, held-item, unknown-outcome and acceptance views with the measures above. Treat migration execution and concurrent-action protection as requirements to prove, not assumed features.”
FAQ
Must every open request move to the new workflow?
No. Decide whether original rules remain acceptable, whether a supported migration exists and what the approved boundary requires. Record the treatment rather than relying on the deployment default.
Does migration repeat completed approval steps?
Do not assume it does. Confirm engine behavior and define any additional review explicitly. Preserve prior decisions with the evidence they actually assessed.
Can we withdraw and recreate requests instead?
Only under an authorized business process that handles existing tasks and external effects, links the records and preserves history. Recreation is not a safe shortcut for an unknown migration outcome.
When is the cutover complete?
When every selected instance has a verified disposition, next owners have accepted their work, and remaining exceptions have explicit owners and approved treatment. A completed administrative job alone does not prove this.
Leave a Reply