从 Activiti 迁移到 Flowable，需要迁移哪些数据库表和流程数据？

从 Activiti 迁移到 Flowable，不能把任务理解为“复制几张 ACT_ 表”。真正的迁移对象是一张有关联的数据图：流程定义、部署资源、执行树、任务、变量、作业、历史、身份、业务单据、表单附件和消息状态共同描述一个流程。

迁移前必须先确认 Activiti 来源版本、目标 Flowable 版本、数据库方言、历史级别、定制扩展和运行实例复杂度。不同版本的可行路线差异很大：有的可以使用官方升级脚本，有的应让旧实例自然跑完，还有的必须按平台迁移重新设计。

一、先给结论：迁移对象不是表，而是关联数据图

图 1　流程定义、运行实例、历史、身份和业务数据必须按关联关系整体评估。

迁移对象至少分为六组：

数据域	典型表或对象	迁移重点
通用与资源	ACT_GE_PROPERTY、ACT_GE_BYTEARRAY	Schema 版本、BPMN/XML、图片和二进制变量
定义与部署	ACT_RE_DEPLOYMENT、ACT_RE_PROCDEF、ACT_RE_MODEL	部署资源、定义版本、模型编辑数据
运行时	ACT_RU_EXECUTION、TASK、VARIABLE、IDENTITYLINK	执行树、任务、变量和候选关系
作业与事件	Timer、Job、Event Subscription 等	表结构变化、锁、重试和异步边界
历史审计	ACT_HI_PROCINST、TASKINST、ACTINST、VARINST	完整轨迹、意见、附件和归档
引擎外数据	业务单、表单、附件、消息、门户待办	业务主键、状态、幂等和审计映射

只复制 ACT_RU_TASK 无法恢复待办，因为任务依赖流程实例、执行实例、流程定义、变量、身份链接和运行作业。只重新部署 BPMN 也不能让新定义接管旧执行树。

二、第一步：确认 Activiti 来源版本

1. Activiti 5.x

Flowable 与 Activiti 5 同源，官方迁移指南提供了从 Activiti 5 到 Flowable 6 的兼容路线。即便如此，也必须按官方版本顺序执行升级脚本，并验证自定义监听器、序列化变量和作业数据。

2. Activiti 6

Activiti 6 与 Flowable 在分叉后分别演进。表名前缀相同不代表官方承诺直接兼容，尤其要关注作业表拆分、公共表、历史表、字段长度和索引差异。应先对比源端真实 DDL 与目标版本脚本，再决定升级还是 ETL。

3. Activiti 7/Cloud

Activiti 7/Cloud 引入 Runtime Bundle、Query、Audit、Connector 和消息组件，迁移通常已经超出数据库升级范围。需要分别处理运行服务、查询审计、事件消息和部署拓扑，更接近平台架构迁移。

版本盘点应记录：

• 引擎准确版本与历次升级路径；
• 数据库类型、字符集和真实 DDL；
• history level 与数据清理策略；
• 自定义表、索引、触发器和存储过程；
• JavaDelegate、监听器、表达式和自定义命令；
• 当前运行实例、作业、定时器和失败任务数量。

三、定义与部署数据怎样迁移

定义域不能只看 ACT_RE_PROCDEF。ACT_RE_PROCDEF 记录流程定义元数据，真正的 BPMN XML、流程图、模型源文件和部分变量二进制内容通常保存在 ACT_GE_BYTEARRAY。

对象	处理建议
ACT_RE_DEPLOYMENT	保留部署 ID、时间、租户和类别关系
ACT_RE_PROCDEF	保留定义 ID、KEY、VERSION、DEPLOYMENT_ID 和资源名
ACT_RE_MODEL	区分运行必需数据和设计器草稿；必要时导出为独立模型资产
ACT_GE_BYTEARRAY	迁移 BPMN、PNG、模型源和变量二进制，并核对引用方
ACT_GE_PROPERTY	不直接照搬目标 Schema 版本号，由官方脚本管理

迁移 BPMN XML 时还要扫描：

• Activiti 专属扩展命名空间；
• class、delegateExpression、listener 和 script；
• 表单键、候选人表达式和自定义属性；
• 多实例、边界事件、调用活动和异步标记；
• 流程定义 KEY、版本和业务启动入口。

更安全的做法是把每个已部署版本导出成独立资源，计算 hash，并在目标环境重新解析和部署；同时保存旧定义 ID 到新定义 ID 的映射。

四、运行实例为什么必须成组处理

运行实例的核心不是一行流程实例，而是一棵执行树。ACT_RU_EXECUTION 通过父子关系、流程实例 ID、定义 ID 和当前活动 ID 组织 Token；任务、变量、身份链接、事件订阅和作业都挂在这棵树上。

活动实例迁移至少要保持以下不变量：

• 每个运行实例都能找到有效流程定义；
• 每个任务都能找到执行实例和流程实例；
• 局部变量的 EXECUTION_ID、TASK_ID 和作用域不丢失；
• 候选人、候选组和任务责任人关系完整；
• 并行、多实例和子流程的父子执行关系一致；
• 定时器、消息订阅和异步作业与当前等待点相符。

作业数据通常是风险最高的一组。Activiti 不同版本和 Flowable 可能使用不同的运行作业、定时作业、挂起作业、死信作业和外部工作表。不要在异步执行器运行时迁移这些表，否则旧节点和新节点可能同时领取任务。

流程变量也常在最后一步暴露问题。字符串、数字和日期容易转换；Java 序列化对象依赖原类名、serialVersionUID 和类加载器，二进制变量还依赖 ACT_GE_BYTEARRAY。建议在迁移前把长期变量转换成 JSON 或明确的基础类型。

五、历史、身份与业务数据如何处理

ACT_HI_* 历史表不仅用于查看已办，还可能承担审计、报表、合规和业务追责。历史处理通常有三种策略：

1. 全量迁移：统一查询体验最好，但转换和验证成本最高；
2. 旧库只读：新历史写入 Flowable，门户聚合新旧查询；
3. 归档到业务数据仓库：适合只需报表和合规检索的已结束实例。

无论采用哪种策略，都要保留流程实例、活动、任务、变量、意见、附件和业务键之间的关系。

ACT_ID_* 是否迁移取决于身份架构。如果企业用户和组织来自 AD、LDAP、IAM 或业务组织中心，通常不应把引擎身份表当作权威来源；但历史任务中的用户 ID 必须继续可解释，离职用户也不能在审计记录中消失。

引擎表之外还要一起处理：

• 业务单据与流程实例 ID；
• 表单定义、表单版本和字段权限；
• 审批意见、签名、附件和抄送记录；
• 门户待办、移动端未读数和消息状态；
• 会签、加签、退回、撤回等平台操作日志；
• 外部系统回调、幂等键和补偿状态。

在云程低代码开发平台这类长期演进系统中，表单、门户和业务模块应依赖稳定流程能力接口，由适配层映射 Activiti 或 Flowable。这样迁移影响集中在适配器和数据转换层。

六、三条迁移路线怎样选择

图 2　默认优先级是旧实例自然跑完，其次官方升级脚本，最后才是活动实例转换。

1. 路线一：旧实例自然跑完

Activiti 停止创建新实例，Flowable 接收新流程；统一门户在过渡期聚合两套待办和历史。此路线风险最低，不必转换执行树，适合流程周期可控、允许双轨运行的系统。

2. 路线二：使用官方升级脚本

适用于官方明确支持的同源版本路线。必须从源版本开始按顺序执行逐版本 DDL，不能跳过中间脚本，也不能只把目标建表脚本覆盖到旧库。

3. 路线三：转换活动实例

只有存量实例无法等待结束、官方路线不覆盖且企业能够承担专项改造时才选择。需要编写 ETL 和映射规则，并对并行、多实例、子流程、作业、局部变量和历史进行专项验证。

路线选择应由“版本兼容性、运行实例复杂度、最长流程周期、停机窗口、双轨能力和审计要求”共同决定，而不是由表数量决定。

七、一套可执行的数据库迁移步骤

图 3　结构升级与业务放量分开执行，异步执行器最后启动。

1. 数据盘点

统计定义、部署、运行实例、任务、变量、作业、历史、身份和业务关联数量；导出真实 DDL，按业务域标记高风险流程。

2. 建立 ID 和关联不变量

明确哪些 ID 原样保留、哪些生成映射；固定业务键、定义 KEY、租户、流程实例和业务单据之间的关系。

3. 在生产副本完整演练

从真实生产快照执行全部 DDL、ETL、模型转换和验证，记录每一步耗时、锁表影响、失败恢复和回滚时间。

4. 冻结与冷备

停止新实例、任务提交、定时器和异步作业，记录冻结水位；备份数据库、对象存储、消息消费位点和应用版本。

5. 执行升级或 ETL

只使用与源版本、目标版本和数据库方言匹配的官方脚本；自定义转换必须可重复、可重入，并记录每批次结果。

6. 先核对数据，再启动异步执行器

先验证定义、人工任务、变量、历史和业务查询；最后再启动 Timer、Job 和异步执行器，避免错误结构被后台线程继续推进。

7. 灰度放量并保留回滚窗口

先开放查询和少量人工任务，再开放新实例和异步处理；明确回滚截止点，超过该点后采用前向修复而不是恢复旧快照。

八、数据校验应该检查什么

数据校验不能只比较总行数，至少包括：

校验维度	示例
数量	定义、实例、任务、变量、作业和历史行数
引用完整性	Task 是否能找到 Execution、ProcInst 和 ProcDef
执行树	父子 Execution、并行分支和多实例计数
变量	类型、作用域、二进制引用和 JSON 可解析性
作业	到期时间、重试次数、锁、异常和死信状态
业务关联	BUSINESS_KEY、业务单状态和流程实例 ID
历史	已办、意见、附件和节点轨迹可查询
行为	迁移后完成任务、触发定时器和消息能正确推进

建议准备一组黄金样本：普通审批、并行网关、会签、子流程、定时器、消息等待、失败作业、退回和撤回实例。每次演练都对比迁移前后的任务、变量、Token、轨迹和业务状态。

九、最常见的迁移误区

• 表都有 ACT_ 前缀，所以可以直接复制；
• 只迁 ACT_RU_TASK 就能恢复待办；
• 重新部署 BPMN 就能接管旧实例；
• 只迁运行表，不处理历史与业务审计；
• 自动 Schema 更新启动成功就代表迁移成功；
• 把 Java 序列化变量当作普通二进制；
• 忽略会签、退回、撤回等平台扩展状态；
• 只有数据库备份，没有旧应用、消息位点和外部副作用方案。

生产迁移建议关闭自动 Schema 更新，使用经过评审和演练的显式脚本。自动升级适合开发环境发现差异，不适合作为不可审计的生产割接方案。

十、最终结论

Activiti 到 Flowable 的迁移不是“表名一样就复制”，也不是“重新部署模型就结束”。定义、资源、执行树、任务、变量、作业、历史、身份和业务数据必须作为关联整体处理。

默认应优先让旧实例自然跑完；官方明确支持时使用逐版本升级脚本；活动实例转换只作为不能双轨、不能等待时的专项方案。

一句话总结：先确定版本和迁移路线，再保护 ID 与关联，最后用真实实例、业务状态和异常路径证明迁移成功。