本文目录
工作流迁移的核心不是复制流程图，而是保持每个实例、任务和副作用只有一个执行主责
面向负责 OA、ERP、CRM、订单、售后或合同审批升级的产品、研发、测试与运维团队：先为流程定义、流程实例、人工作业、定时器、消息订阅和外部副作用建立可核对身份，再按实例创建时间、业务范围与当前等待状态选择原地排空、实例迁移或受控重建。新旧引擎并行时必须以路由账本确定唯一主责，审批入口、回调、催办、超时和接口重试都先查询归属；切换成功以业务结果、待办完整性、审计链和可恢复性为准，不以新引擎已启动或流程图可部署为准。
先按流程寿命与当前状态选择迁移路线
| 流程情况 | 建议路线 | 主要风险 |
|---|---|---|
| 短流程且可等待结束 | 旧引擎停止接收新实例，现有实例继续完成；新申请按确定边界进入新引擎 | 页面或接口仍绕过路由创建旧实例，排空周期永远无法结束 |
| 长流程或不可等待 | 对可映射的等待状态制定逐版本迁移计划，先试点再分批转移实例和关联任务 | 只迁业务变量，遗漏定时器、消息订阅、局部变量、并行分支或任务身份 |
| 引擎差异大且无法原位迁移 | 在业务安全点冻结旧实例，以业务快照在新引擎受控重建并保存新旧身份映射 | 把重建当成普通重试，重复扣款、发券、发送或写入外部系统 |
| 高风险或异常实例 | 保留旧引擎只读与受控处置能力，逐笔决定排空、修复、终止或人工接管 | 为了追求统一版本强制批量迁移，导致流程进入现实中不可达的状态 |
适用边界：审批工作流、业务规则和定时任务不是同一件事
本文适用于有持久化流程实例、人工待办、自动服务任务、定时器或消息等待的旧工作流升级。它不替代业务规则梳理、账号认证改造，也不把所有后台定时任务都包装成流程实例。
先写清迁移对象：流程定义决定路径，流程实例记录一次业务运行，人工作业代表待处理责任，变量保存上下文，定时器和消息订阅决定未来唤醒，历史事件用于解释发生过什么。旧系统还可能把审批状态同时写入业务表、流程表、待办表、消息表和搜索索引；这些副本的权威关系必须先确认。
若旧系统只有一个 status 字段和几段条件代码，没有可恢复的流程运行状态，就应先还原状态机与业务不变量，而不是假设能直接使用引擎迁移功能。若流程涉及付款、授信、医疗、用印或其他高风险动作，人工复核和行业要求优先于通用迁移效率；本文也不承诺更换引擎会自动改善审批周期或管理效果。
- 列清流程定义、实例、任务、变量、定时器、消息、附件与历史的权威来源。
- 区分流程编排、业务规则、权限判断和普通调度任务，分别设定责任。
- 明确哪些动作不可重复、哪些状态不可倒退、哪些记录必须长期保留。
从真实实例反推流程契约，不只阅读最新流程图
生产中的实例可能来自多个旧版本，并停留在不同分支、会签、子流程或异常状态。只按最新版流程图设计迁移，会遗漏仍然有效的历史路径。
按流程类型与定义版本盘点实例数量和状态类别，记录业务主键、实例标识、当前活动节点、并行令牌、父子流程、任务候选人和办理人、局部与全局变量、截止时间、重试与事故、消息关联键、外部动作记录及最后变更时间。样本必须覆盖正常、退回、撤回、转办、加签、会签、超时、补偿、暂停和人工修复，不用一条顺利流程代表全部。
同时反查所有入口和出口：Web、管理后台、小程序、APP、AI 智能体、批量导入、开放 API 如何创建和推进实例，邮件短信、Webhook、定时扫描与人工脚本如何完成任务。为每个动作固定业务命令 ID、业务主键、流程实例 ID、任务 ID 和调用结果的关系，避免迁移后只能靠姓名、标题或时间猜测同一笔审批。
- 按定义版本和活动状态生成可复核清单，并保存盘点时刻。
- 为退回、会签、边界定时器、消息等待、子流程和异常实例准备代表样本。
- 所有创建、完成、撤回、催办、回调和人工修复入口都有调用方负责人。
把流程版本与活动状态映射写成可执行迁移计划
新流程定义上线后，新实例可以使用新版本，但旧实例是否继续旧版本、迁到新版本或受控重建，必须逐类决定。一个“迁到最新版”的按钮不能替代状态语义审查。
为每个来源定义版本建立目标版本、允许迁移的活动节点、节点映射、变量转换、任务处理、定时器语义、消息订阅、子流程关系和失败处置。节点名称相同不代表语义相同；审批人选择方式、输入映射、截止时间或后续副作用变化时，要确认已有任务究竟保持旧语义还是重新创建。并行网关、循环、多实例会签和嵌套子流程需要单独验证令牌数量与完成条件。
Camunda 8 当前官方资料说明，流程实例迁移需要显式映射活动元素，并有元素类型、作用域、等待状态和消息订阅等限制；迁移活动任务时，已有作业、表达式和输入映射也不会当然按新定义重建。该产品行为只作为风险样例，实际项目必须以所用引擎、版本和自定义扩展的官方说明及试验结果为准。不能迁移的状态可以先在旧流程推进到约定安全点、继续排空，或用有审计记录的受控重建处理。
- 每个来源版本都有目标路线：排空、原位迁移、受控重建或保留处置。
- 节点映射同时说明变量、任务、计时、订阅、并行令牌和后续动作语义。
- 先在非生产环境使用生产形态样本验证，迁移失败保持源实例可继续处理。
保持待办、身份与审计链连续，避免“流程还在但没人看得见”
流程引擎中的活动任务只是技术状态，用户实际依赖的是工作台中的可见待办、候选范围、代理转办、表单、附件、意见和通知。迁移必须同时验证办理体验与授权结果。
为每个人工作业保存稳定的业务任务标识、新旧技术任务映射、所属实例和业务单据、节点语义、创建与到期时间、候选组织、当前办理人、委托关系、表单版本和可见数据范围。账号合并、离职、部门调整和角色重命名要经过明确映射；无法确认的新办理人不能自动继承敏感待办。完成任务时重新校验当前业务权限，同时保留当时的办理身份和意见证据，避免用当前组织结构改写历史。
待办聚合层可以在并行期合并新旧来源，但每一条任务必须携带来源与路由身份，点击后只调用所属引擎。历史页面应能从业务单据追到新旧实例、迁移批次、节点变化、人工操作和外部动作，不要求伪造一条从未真实发生的统一时间线。附件继续沿用业务权限和稳定附件 ID；邮件、短信或推送中的旧深链要通过受控路由解析，不能把任务表复制到新库后就让两边都可完成。
- 同一待办在聚合页面不会重复出现，也不会同时被新旧引擎完成。
- 候选人、办理人、代理、组织和数据权限的迁移前后结果可逐项比较。
- 意见、附件、表单版本、迁移事件和历史动作能够按业务单据追溯。
用路由账本固定唯一执行主责，封住重复副作用
双轨运行最危险的不是两套页面，而是两套引擎都能接收同一回调、触发同一超时或执行同一服务任务。主责必须由持久化事实决定，而不是由哪个服务先收到请求决定。
建立以业务流程类型和业务主键为索引的路由账本，记录实例所属引擎、定义版本、迁移批次、状态和切换时间。创建申请先原子确定归属，再启动对应实例；完成任务、撤回、回调、消息关联、催办和超时扫描都先解析归属。迁移实例时采用受控状态转换，例如旧主责、迁移中、新主责或需人工处置，任何时刻只允许一个引擎推进业务。路由变更与实例迁移结果应能对账，失败时不得提前开放新入口。
自动任务使用稳定业务命令 ID 调用下游，让付款、库存、发券、通知和第三方写入能识别重复意图。Camunda 8 官方 job worker 文档说明其任务交付可能至少一次，处理代码需要幂等；其他引擎、队列和自研重试也应按实际语义验证。幂等不能只做进程内锁，应在权威数据侧记录命令、结果和未知状态。遇到请求已发出但结果未确认时先查询或对账，不用盲目重试制造第二次副作用。
- 实例归属、迁移状态与路由更新时间保存在可事务更新、可审计的账本中。
- 回调、定时器、消息、人工操作和自动任务共享同一归属判断。
- 每个外部副作用有稳定命令 ID、结果查询、重复拒绝与结果未知处置。
实施步骤：先接管新建路由，再分批处理在途实例
先把新申请稳定送到唯一入口，才能建立清晰迁移边界。在途实例按照定义版本和等待状态分批，不在同一窗口同时改流程模型、身份体系、表单和所有外部接口。
第一步冻结真实流程和调用清单；第二步建立统一业务标识、路由账本和新旧查询视图；第三步让新引擎在影子环境重放脱敏事件或无副作用验证路径；第四步先迁无实例的低风险流程，新申请进入新引擎，旧实例继续排空；第五步选取可恢复的等待状态试迁，迁移前后比较活动节点、任务、变量、计时、订阅与业务状态；第六步按流程、组织或业务范围扩大；第七步处理长期挂起与异常实例；第八步在观察期完成后停止旧创建入口并把旧引擎转为受控只读。
每批迁移生成不可变清单，记录来源与目标定义、实例映射、开始结束时间、转换版本、逐项结果和审批人。迁移期间暂停对应实例的用户提交与自动推进，或使用引擎提供的安全等待/暂停能力；但要验证已经在外部执行的任务是否真的停止。批次失败只回退该批路由并恢复源实例处理，不删除新历史或强行把部分成功标为完成。
- 上线顺序为统一入口与观测、新实例切换、可迁实例试点、分批扩大、异常收尾。
- 迁移窗口明确如何冻结用户动作、定时器、消息和正在执行的外部任务。
- 每批有停止条件、回退负责人、逐实例结果和新旧状态对账。
验收与风险：按业务结果、在途守恒和恢复能力判断完成
迁移成功不能只看实例数相等。必须证明没有申请丢失、没有重复待办、没有越权办理、没有定时器提前或漏触发，并且关键业务副作用与审计记录一致。
验收至少覆盖新申请、旧实例排空、活动任务迁移、退回与撤回、转办与代理、会签、子流程、消息回调、超时升级、失败重试、结果未知、权限变更和历史查询。按迁移边界核对来源实例数、排空数、迁移成功数、人工处置数与仍在源端数；按业务主键核对最多一个活动主责；按用户核对待办和已办；按不可重复动作核对业务流水与命令记录。观察周期应覆盖实际最长的关键等待和业务结算周期，不套用统一天数。
回滚先停止新批次和路由变更，再判断哪些实例可恢复源引擎、哪些已产生新任务或外部事实只能前滚处置。若新引擎已完成付款、通知或状态更新，不能简单把旧实例解除冻结后重新执行。主要风险包括隐藏入口继续创建旧实例、流程版本映射过度简化、历史身份失真、定时器重置、消息订阅重复、并行令牌丢失、表单与变量不兼容、外部作业未停止、旧深链失效以及回滚形成双主。旧引擎退役前仍需验证备份恢复、历史查询、审计导出和剩余实例为零或均有批准处置。
- 实例、任务、路由、业务单据和外部命令可按稳定身份双向追踪。
- 待办守恒、权限结果、定时器消息、并行分支与不可重复动作均已对账。
- 回滚演练区分可逆运行状态与已经发生的业务事实，并证明不会恢复双主。
需求讨论中的问题
旧流程可以全部留在原引擎跑完，只让新申请进入新引擎吗？
可以，而且对短流程通常更稳妥，但前提是所有创建入口都经过统一路由，旧引擎能在排空期安全运行，用户能同时看到新旧待办，且旧版本依赖、账号和运维能力不会在实例结束前失效。
把流程实例表和任务表复制到新数据库，是否就完成了在途迁移？
通常没有。还要处理引擎内部令牌、局部变量、定时器、消息订阅、并行分支、子流程、任务身份和外部作业。直接复制内部表可能破坏引擎约束，应优先使用所用产品支持的迁移能力或经过验证的受控重建。
流程节点名称相同，能否直接一一映射？
不能只看名称。要比较节点类型、作用域、输入输出、审批人规则、计时、边界事件、并行完成条件和后续副作用。相同名称也可能代表不同业务语义，不兼容状态应排空或在安全点重建。
迁移时如何避免重复发短信、扣款或写入第三方系统？
先以路由账本保证只有一个引擎推进，再为每个外部动作使用稳定业务命令 ID，在权威下游记录已受理与最终结果。请求超时或结果未知时先查询和对账，不能仅靠重试次数或进程锁。
回滚是不是把路由切回旧引擎即可？
只有尚未迁移且未产生新业务事实的实例才可能直接恢复。已经在新引擎完成任务、改变业务状态或执行外部动作的实例，通常需要保持新主责并前滚修复，或制定逐笔补偿，不能重新激活旧节点。
AI 智能体可以替用户自动审批吗？
是否允许取决于业务授权和风险。更稳妥的做法是让智能体通过版本化、可审计的工具读取材料、生成建议或发起流程；最终审批、权限校验和高风险副作用仍由明确的业务规则与责任主体控制。
旧审批工作流迁移验收清单
可逐项勾选，辅助本次阅读；刷新页面后不保留。
参考资料
技术概念可进一步阅读以下资料；文中的业务场景与实施清单用于方案讨论。
- Camunda 8 Docs · Process instance migration
核对当前流程实例迁移需要活动元素映射、存在元素类型与作用域等限制，以及活动作业、表达式和输入映射不会当然按目标定义重建；实际项目按采用产品和版本验证。
- Camunda 8 Docs · Migration journey
核对跨引擎迁移中的运行实例、等待状态、排空与大切换路线，以及先将实例推进到可迁移安全状态的官方建议。
- Camunda 8 Docs · Job workers
核对任务激活超时后可能重新分配、作业可能至少一次执行，因此外部处理需要幂等并处理结果未知；其他引擎以自身语义为准。
- OMG · Business Process Model and Notation 2.0.2
核对 BPMN 2.0.2 规范入口及流程元素的标准语义；BPMN 图本身不替代具体引擎的运行状态、迁移能力与实现限制。
旧 OA 或业务审批里有大量在途实例，不敢直接换引擎？
提供脱敏后的流程版本、活动状态、待办样例、外部动作和现有切换限制，月弦科技可以协助整理排空、实例迁移、双轨路由与验收回滚范围。