工作流迁移映射表把来源系统里的每个工作流、状态、流转规则、字段规则、权限和扩展能力，逐条对应到目标系统的配置上，并记录迁移方式、验证结果和负责人。本文提供可直接复制到表格工具的空白主表与两张子表、逐列字段说明、必填与选填划分、一条需求工作流的完整填写示例，以及迁移推进中的调整与归档方法。适用范围限于行为与能力迁移，记录数据的批量搬运和字段值转换不在本表登记。
要点总览（TL;DR）
- 工作流迁移映射表由一张主表和状态语义、扩展能力两张子表组成，用“映射编号”把工作流、状态和插件/自动化/接口的对应关系串起来。
- 主表必填映射编号、来源与目标工作流、映射结论、迁移方式、验证方式、验证结果和负责人；差异说明、备注等按适用时机补填。
- 填写时把“映射结论”和“验证结果”分开：结论只填等价、需重建、需替代或暂缓，未验证一律写“待验证”。
- 示例以一条需求工作流演示主表与两张子表的联动，状态拆分和插件部分对应都能在子表中找到依据。
- 模板随盘点、设计、执行、验证四个阶段只增列不删列，用版本记录表和一名维护人保证前后版本可对照。
可复制空白模板：工作流迁移映射表
模板由一张主表和两张子表组成。主表按“一个工作流一行”登记整体映射；状态语义子表按“一个状态一行”登记状态含义的对应关系；扩展能力子表按“一项插件、自动化规则或接口一行”登记替代方案。三张表通过“映射编号”关联，复制到表格工具后保持编号列在最左侧。
主表：工作流迁移映射主表
| 映射编号 | 来源系统 | 来源工作流/项目 | 工作流用途 | 目标系统 | 目标工作流/项目 | 映射结论 | 迁移方式 | 差异说明 | 验证方式 | 验证结果 | 负责人 | 计划完成时间 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| WF-001 | |||||||||||||
| WF-002 |
子表一：状态语义对照表
| 映射编号 | 来源状态 | 来源状态含义 | 目标状态 | 目标状态含义 | 语义是否一致 | 处理方式 | 负责人 |
|---|---|---|---|---|---|---|---|
| WF-001 | |||||||
| WF-001 |
子表二：扩展能力对照表
| 映射编号 | 能力名称 | 能力类型 | 来源实现方式 | 使用范围 | 目标实现方式 | 对应程度 | 差异与限制 | 验证结果 | 负责人 |
|---|---|---|---|---|---|---|---|---|---|
| WF-001 | |||||||||
| WF-001 |
复制到表格工具后，建议把“映射编号”列宽设为 90 像素左右并冻结首列，主表冻结首行表头；状态语义子表和扩展能力子表按映射编号排序，便于与主表逐行对照。差异说明、备注这类长文本列宽度设为 240 像素以上并开启自动换行，避免内容被截断后误读。
字段说明：每一列登记什么、怎么填
字段说明与上面的模板同名同序。填写时先保证口径统一，再追求填得细；同一列在不同行出现两种写法，后续核对成本会明显上升。
主表字段说明
| 字段 | 登记内容 | 取值口径 |
|---|---|---|
| 映射编号 | 本条映射的唯一标识 | 建议“WF-三位序号”，子表沿用同一编号 |
| 来源系统 | 当前工作流所在的系统 | 写系统名称，不写服务器或环境地址 |
| 来源工作流/项目 | 工作流名称及其所属项目 | 名称照抄来源系统，便于回查 |
| 工作流用途 | 该工作流支撑的业务过程 | 一句话说明，如“需求从提出到上线” |
| 目标系统 | 迁移后承载的系统 | 写系统名称 |
| 目标工作流/项目 | 目标侧对应的工作流或项目 | 尚未创建时写“待建”，不要留空 |
| 映射结论 | 本条映射的判定结果 | 从“等价、需重建、需替代、暂缓”中选一个 |
| 迁移方式 | 通过什么手段完成迁移 | 如配置迁移、手工重建、流程自动化替代 |
| 差异说明 | 两侧行为或能力上的不同 | 只写差异事实，不写评价 |
| 验证方式 | 如何确认映射可用 | 如走查一条完整流转、抽样比对状态 |
| 验证结果 | 验证后的实际结论 | 未验证时写“待验证”，不要提前写“通过” |
| 负责人 | 对该条映射负责的人 | 写姓名，不写团队名 |
| 计划完成时间 | 该条映射的计划完成日期 | 统一日期格式 |
| 备注 | 补充信息 | 记录依赖、阻塞或待确认事项 |
状态语义子表字段说明
| 字段 | 登记内容 | 取值口径 |
|---|---|---|
| 映射编号 | 所属主表映射 | 与主表一致 |
| 来源状态 | 来源系统中的状态名 | 照抄原名 |
| 来源状态含义 | 该状态在业务上的含义 | 写进入和离开该状态的条件 |
| 目标状态 | 目标系统中的状态名 | 尚未确定时写“待定” |
| 目标状态含义 | 目标状态承担的业务含义 | 与来源含义逐条对照 |
| 语义是否一致 | 两侧含义是否相同 | 填“一致”“部分一致”“不一致” |
| 处理方式 | 语义不一致时怎么处理 | 如合并状态、拆分状态、调整流转条件 |
| 负责人 | 状态映射的确认人 | 写姓名 |
扩展能力子表字段说明
| 字段 | 登记内容 | 取值口径 |
|---|---|---|
| 映射编号 | 所属主表映射 | 与主表一致 |
| 能力名称 | 插件、自动化规则或接口的名称 | 写实际使用的名称 |
| 能力类型 | 能力的归类 | 填“插件”“自动化”“接口”之一 |
| 来源实现方式 | 来源系统中如何实现该能力 | 写插件名或规则描述 |
| 使用范围 | 哪些项目或团队在用 | 写项目名或团队名 |
| 目标实现方式 | 目标系统中用什么承载 | 写标准能力、自动化规则或开放接口 |
| 对应程度 | 两侧能力的接近程度 | 填“可对应”“部分对应”“需定制”“无对应” |
| 差异与限制 | 替代后缺失或变化的行为 | 写具体行为差异 |
| 验证结果 | 替代方案的实际验证结论 | 未验证写“待验证” |
| 负责人 | 该能力的评估人 | 写姓名 |
易错字段集中在三处。“映射结论”常被填成迁移动作，应只填判定结果；“验证结果”容易在验证前就写成“通过”，未验证一律写“待验证”；“语义是否一致”容易凭状态名判断，实际要按进入和离开条件比对。扩展能力子表的“对应程度”也常被写成“可以替代”，应落到四档取值上，差异另填在“差异与限制”列。
必填与选填：哪些列不能空
必填列的作用是保证每条映射可追溯、可验证、有人负责。缺任何一项，这条映射在评审时都无法判断是否完成，因此必填列在首次登记时就要填满，不能留到迁移后期补。
| 表 | 必填列 | 选填列 |
|---|---|---|
| 主表 | 映射编号、来源系统、来源工作流/项目、目标系统、目标工作流/项目、映射结论、迁移方式、验证方式、验证结果、负责人 | 工作流用途、差异说明、计划完成时间、备注 |
| 状态语义子表 | 映射编号、来源状态、来源状态含义、目标状态、语义是否一致、负责人 | 目标状态含义、处理方式 |
| 扩展能力子表 | 映射编号、能力名称、能力类型、来源实现方式、目标实现方式、对应程度、负责人 | 使用范围、差异与限制、验证结果 |
选填列有明确的适用时机。“差异说明”在两侧行为不完全相同时必须补上，等价映射可以留空；“处理方式”只在语义不一致时填写；“使用范围”在能力被多个项目共用时填写，用于判断替代方案的影响面；“验证结果”在扩展能力完成验证后回填。计划完成时间在映射进入排期后填写，尚未排期的条目可以暂空。
必填缺失按统一约定处理：登记人当天补齐；确实无法确定的，在对应单元格写“待确认”并在备注列写明待确认对象和确认时间，不允许直接留空。评审前由负责人统一检查一遍必填列，存在空白或“待确认”超过约定时间的条目，不进入迁移执行清单。这样处理的意义在于，映射表的完成度可以直接用必填列的填写情况衡量，而不依赖个人记忆。
填写示例：一个需求工作流的完整映射
以下示例为演示情景，来源系统以常见的研发管理工具代称，目标系统为 ONES，用于说明主表与两张子表如何联动填写，不对应任何真实项目。
示例背景与范围
某研发团队把“需求管理”工作流从原系统迁移到 ONES Project。原工作流包含待评估、已排期、开发中、待验收、已上线五个状态，使用一个用于自动分配经办人的插件，并配置了按需求类型区分字段的规则。本次只登记工作流行为与能力的映射，历史需求数据的搬运不在本表范围。
主表填写行
| 映射编号 | 来源系统 | 来源工作流/项目 | 工作流用途 | 目标系统 | 目标工作流/项目 | 映射结论 | 迁移方式 | 差异说明 | 验证方式 | 验证结果 | 负责人 | 计划完成时间 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| WF-001 | 原研发管理工具 | 需求管理 / 产品需求项目 | 需求从提出到上线 | ONES | 需求管理 / 产品需求项目 | 需重建 | 配置迁移加手工重建 | 原状态“待验收”在目标侧拆为“待验收”和“验收中” | 走查一条需求完整流转并抽样比对状态 | 待验证 | 张明 | 2025-06-20 | 依赖扩展能力 EX-001 的替代结论 |
状态语义子表对应行
| 映射编号 | 来源状态 | 来源状态含义 | 目标状态 | 目标状态含义 | 语义是否一致 | 处理方式 | 负责人 |
|---|---|---|---|---|---|---|---|
| WF-001 | 待评估 | 需求提交后等待产品负责人评估 | 待评估 | 需求提交后等待产品负责人评估 | 一致 | 张明 | |
| WF-001 | 已排期 | 评估通过并进入版本计划 | 已排期 | 评估通过并进入版本计划 | 一致 | 张明 | |
| WF-001 | 开发中 | 研发已领取并开始实现 | 开发中 | 研发已领取并开始实现 | 一致 | 张明 | |
| WF-001 | 待验收 | 开发完成，等待测试或产品验收 | 待验收、验收中 | 待验收为排队，验收中为正在验收 | 部分一致 | 拆分为两个状态，并补充进入验收中的条件 | 张明 |
| WF-001 | 已上线 | 需求随版本发布上线 | 已上线 | 需求随版本发布上线 | 一致 | 张明 |
扩展能力子表对应行
| 映射编号 | 能力名称 | 能力类型 | 来源实现方式 | 使用范围 | 目标实现方式 | 对应程度 | 差异与限制 | 验证结果 | 负责人 |
|---|---|---|---|---|---|---|---|---|---|
| WF-001 | 经办人自动分配 | 插件 | 原系统插件按模块轮询分配 | 产品需求项目 | 流程自动化规则按模块指定负责人 | 部分对应 | 轮询逻辑需改为按模块固定负责人，跨模块轮询暂不实现 | 待验证 | 李华 |
| WF-001 | 需求类型字段规则 | 自动化 | 原系统按需求类型显示不同字段 | 产品需求项目 | 工作项类型配合字段配置 | 可对应 | 字段必填条件需逐项重新配置 | 待验证 | 李华 |
示例与字段说明的一致性核对
核对时看三点。第一，主表 WF-001 的映射结论是“需重建”，与状态子表中“待验收”被拆分、扩展能力子表中插件为“部分对应”相互印证，结论与明细不矛盾。第二，所有子表行的映射编号都能在主表找到对应行，没有孤立记录。第三，验证结果统一写“待验证”，没有在验证前提前写“通过”。这三项检查可以直接作为每次评审的固定动作。
在目标侧重建状态和字段规则时，ONES 的工作项类型、状态与字段配置是承载这些映射结论的配置对象。以示例中的“需求类型字段规则”为例，迁移负责人需要把原系统按需求类型区分字段的做法，落到目标侧的工作项类型与字段配置上，再回到扩展能力子表登记对应程度和差异。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程等对象的迁移，其中系统配置包括问题类型、工作流、字段配置、权限配置等，可作为登记目标侧配置时的参照；具体覆盖范围以实际迁移评估为准。
调整与维护方法：迁移推进中怎么改这张表
映射表在迁移不同阶段承担不同任务，列和子表需要随阶段调整，但主键和字段名保持稳定，避免前后版本无法对照。
按迁移阶段调整列与子表
- 盘点阶段：以主表为主，重点填来源工作流、用途和负责人，先保证工作流清单完整。
- 设计阶段：补齐目标工作流、映射结论和迁移方式，同步展开状态语义子表，把状态含义逐条比对。
- 执行阶段：展开扩展能力子表，逐项登记插件、自动化和接口的替代方案，并开始填写验证方式。
- 验证阶段：集中回填验证结果，把“待验证”逐条清零，未通过的条目在备注列写明原因和下一步。
阶段推进时只增列不删列。需要补充信息时在表尾追加新列，例如执行阶段可增加“依赖条目”列记录映射之间的先后关系；已经填过的列即使后续不再使用，也保留并标注停用日期，便于回溯当时的判断依据。
新增映射对象的登记规则
迁移中发现新的工作流、状态或插件时，按以下规则登记：新工作流分配新的 WF 编号，不复用已归档编号；已有工作流下新增状态，直接在状态语义子表追加行并沿用原映射编号；新增插件或自动化规则，在扩展能力子表追加行，能力类型按实际归类填写。新增条目当天完成必填列填写，并在主表备注列注明“新增”及发现场景，方便评审时区分初始盘点与后续补充。
版本记录与责任人维护
在表格底部增加一张版本记录表，结构如下：
| 版本号 | 修改日期 | 修改人 | 修改内容 | 影响范围 |
|---|---|---|---|---|
| V1.0 | ||||
| V1.1 |
每次批量修改列结构、调整映射结论或新增子表时记一条版本，写明影响到的映射编号范围。责任人分两层：每条映射有填写负责人，整张表有一名维护人，负责合并修改、检查必填列和发布新版本。维护人变更时在版本记录中注明交接日期，避免出现无人认领的条目。
迁移完成后的归档方式
迁移验收通过后，把表格状态改为“已归档”，停止新增条目，保留最后一次版本记录。归档时做三件事：将验证结果全部为“通过”的条目与仍有差异的条目分开标记；把扩展能力子表中“需定制”“无对应”的条目单独导出，作为后续配置治理的输入；将整张表连同版本记录存入项目文档库，并在文件名中标注归档日期和覆盖的工作流范围。归档后的表格作为迁移过程的记录保留，日常配置调整转入目标平台的配置管理流程，不再回写这张表。
常见问题
来源系统里一个工作流对应目标系统多个工作流时，主表怎么登记？
按“一个来源工作流一行”登记主表，在“目标工作流/项目”列写明拆出的多个目标工作流，并在“差异说明”列写清拆分依据。拆出的每个目标工作流如果需要单独跟踪验证，可以另起 WF 编号登记为独立映射，并在备注列注明与原编号的关系。这样主表仍保持来源侧清单完整，目标侧的拆分细节不会丢。
状态语义子表里“部分一致”的状态，处理方式必须写到什么程度？
写到能指导配置的程度即可，至少说明是合并、拆分还是调整流转条件，并写清进入和离开该状态的条件。例如“拆分为待验收和验收中，验收中需由测试人员领取后进入”。如果处理方式还依赖其他映射条目，在负责人列之外通过备注或主表备注注明依赖关系，避免执行时才发现前置条件未定。
扩展能力子表里“无对应”的条目，迁移时怎么处理？
“无对应”表示目标侧暂时没有可承载该能力的标准方式，需要在“差异与限制”列写清缺失的具体行为，并在主表备注列登记后续安排，例如改为人工操作、调整流程或列入后续配置治理。归档时这类条目单独导出，作为迁移后配置治理的输入，不留在映射表里当作已完成项。
迁移进行到一半发现初始盘点漏了一个工作流，编号怎么处理？
给新发现的工作流分配新的 WF 编号，不复用已归档编号，当天补齐必填列，并在主表备注列注明“新增”和发现场景。如果该工作流与已有条目存在依赖，在执行阶段追加的“依赖条目”列中写明。评审时通过备注列的“新增”标记区分初始盘点与后续补充，便于评估盘点完整度。
映射表归档后，日常新增的状态或字段规则还要回写吗？
不回写。归档后的表格作为迁移过程的记录保留，日常配置调整转入目标平台的配置管理流程。归档时把仍有差异的条目和“需定制”“无对应”的扩展能力条目单独导出，作为后续配置治理的输入；如果后续治理需要追溯迁移时的判断依据，再查阅归档表对应编号即可。
