工作流迁移映射表要把源系统里的状态、流转、字段规则、权限、自动化与接口拆成可逐行核对的记录，写清源端定义、目标端承载方式、映射类型和验证证据。设计前先锁定源与目标的版本和对象范围，再用试迁移验证关键路径，最后以核验清单和回退条件收口。本文给出一份可直接填写的表结构与配套方法。
要点总览（TL;DR）
- 映射表以源到目标为方向，按状态、流转、字段规则、权限、自动化、接口六类对象分行，每行写清源端定义、目标端承载方式、映射类型和验证证据。
- 设计前先锁定源与目标的版本、纳入迁移的工作流清单和排除项，并把源端配置导出、目标端可配置能力确认、业务口径确认列为前置输入。
- 映射类型统一为等价、改写、重建、舍弃四类；同名字段含义不同要拆分，状态合并、拆分或新增都要同步调整流转条件与权限。
- 试迁移选取覆盖主流程、异常分支和跨角色审批的代表性工作流，留存配置对照、流转结果和权限验证三类证据，问题未关闭的行不进入切换清单。
- 切换前设定映射表完成度与核验通过标准，并预设回退触发条件、回退范围和无法映射对象的挂起处理方式。
迁移范围与源目标基线怎么锁定
映射表失控通常从范围不清开始：有人把整个空间的工作流都列进来，有人只凭印象挑几条主流程，结果表越填越长，责任却对不上。第一步应产出一张迁移范围基线表，把“迁什么、从哪迁到哪、什么版本、谁负责”固定下来，后续所有映射行都挂在这张基线之下。
基线表建议包含以下字段：源系统名称与版本、目标系统名称与版本、迁移方向（源到目标，单向记录）、纳入迁移的工作流清单、每个工作流所属的项目或空间、涉及的对象类型（工作项类型、字段、状态、流转、权限方案、自动化规则、接口调用）、排除项及排除原因、基线确认人与确认日期。
纳入范围的判断可以按三个条件筛：该工作流仍在被业务实际使用；该工作流承载的过程数据需要延续；目标端具备对应的承载方式或已确认替代方案。三个条件都不满足的，可以列入排除项并写明原因，例如已停用的历史流程、仅用于一次性活动的临时流程、目标端明确不承接的配置类型。
迁移阶段也要在基线中标注。常见划分是准备（资料收集与口径确认）、映射（填表与语义对齐）、试迁移（代表性流程验证）、切换（正式迁移与观察）。每个阶段对应映射表的不同完成状态，避免把“已填完”误当成“已验证”。
| 基线项 | 记录内容 | 示例 |
|---|---|---|
| 源系统与版本 | 产品名、版本号、导出时间 | 源平台 9.x，配置导出日期 3 月 1 日 |
| 目标系统与版本 | 产品名、版本号、环境 | 目标平台当前生产版本，测试环境先行 |
| 纳入对象 | 工作流、项目/空间、对象类型 | 研发需求与缺陷两条主流程，含字段与权限方案 |
| 排除项 | 对象与原因 | 已停用的旧审批流，业务确认不再使用 |
| 阶段与责任人 | 当前阶段、确认人 | 映射阶段，业务负责人与平台管理员双签 |
映射表需要哪些输入和前置依赖
映射表的每一行都应能追溯到一份源端材料，否则填写就变成凭记忆复述。设计前需要把输入清单列全，并指定每项输入的提供人和截止时间，形成输入依赖清单。
源端输入通常包括：工作流与状态列表的导出或截图、每个状态的流转条件与审批节点、字段清单及字段类型与必填规则、权限方案与角色对应关系、自动化规则（触发器、条件、动作）、对外接口与集成调用清单。截图要标注版本和截取时间，导出文件要保留原始格式，便于后续复核。
目标端输入包括：可配置能力的确认方式，例如由平台管理员在测试环境实际配置一遍状态机、字段和权限方案，记录哪些能直接配置、哪些需要组合实现、哪些存在限制。确认结论要落到具体配置项，不停留在“应该可以”。
业务侧输入是容易被低估的一项。状态语义和审批规则需要业务方给出统一口径：某个状态在业务上代表什么、谁能推进、推进前必须满足什么条件、审批不通过时回到哪里。这些口径由业务负责人确认并签字，后续映射判定以确认版本为准。
所有输入进入版本冻结。冻结后源端或目标端发生配置变更，必须走变更控制：登记变更内容、影响哪些映射行、由谁更新、是否需要重新核验。没有变更控制的映射表，在试迁移阶段往往已经和实际配置脱节。
映射表按什么结构设计：六类对象与字段列
映射表以源到目标为方向，按对象类型分行。六类对象分别是状态、流转、字段规则、权限、自动化、接口。每类对象给一个唯一标识，例如“WF-需求流程-状态-待评审”，保证跨表引用和问题追踪时能精确定位。
列定义建议如下，可直接作为模板使用：
| 列名 | 填写规则 |
|---|---|
| 对象ID | 工作流缩写+对象类型+序号，全局唯一 |
| 对象类型 | 状态、流转、字段规则、权限、自动化、接口之一 |
| 所属工作流/项目 | 关联基线表中的工作流与空间 |
| 源端定义 | 名称、类型、条件、角色等原始定义，附来源材料位置 |
| 目标端承载方式 | 目标系统中对应的状态、字段、权限方案或规则配置 |
| 映射类型 | 等价、改写、重建、舍弃 |
| 差异说明 | 改写与重建必填，说明差异原因与业务影响 |
| 责任人 | 该行的配置责任人与业务确认人 |
| 验证状态 | 待映射、已映射、试迁移通过、已验证、挂起 |
| 证据位置 | 配置对照截图、流转结果记录、权限验证记录的存放位置 |
映射类型需要统一口径：等价指源端与目标端语义和效果一致；改写指语义保留但实现方式调整，例如流转条件从单一字段判断改为组合条件；重建指目标端没有直接对应物，需要用其他机制重新搭建，例如用自动化规则替代原有的脚本触发；舍弃指该对象不迁移，必须记录业务影响和替代安排。
状态语义与流转条件要分开记录。状态行写清状态名称、业务含义、进入条件、可停留时长（如有）；流转行写清起点状态、终点状态、触发动作、执行角色、附加条件。这样在语义冲突时能定位到具体是状态定义问题还是流转规则问题。
映射表落地到具体平台时，状态机、字段配置和权限方案需要逐项对照配置。ONES 从 Jira 迁移到 ONES Project 的场景中，可迁移项目与系统配置，包括问题类型、工作流、字段配置、权限配置等，映射表中的对应行可以在目标端配置完成后回填承载方式并附上配置对照记录；具体可迁移项与等价程度以迁移工具和项目评估结果为准。
同名字段含义不同、状态语义不一致怎么映射
语义冲突是映射表里最需要人工判断的部分，处理原则是先对齐语义，再决定映射类型，不能因为名称相同就默认等价。
同名字段含义不同，先做识别与拆分。典型情形是源端一个“优先级”字段同时承载业务紧急度和排期顺序，目标端拆成两个字段。处理方式是：在映射表中把源字段拆成两行，分别对应目标端的两个字段，写明拆分规则（例如按取值区间或按来源团队区分），并记录拆分后可能丢失的组合信息。若无法拆分，则标记为改写并说明降级方式。
状态语义不一致分三种情况处理。状态合并：源端多个状态在业务上属于同一阶段，目标端合并为一个状态，需要确认审批节点是否随之合并、统计口径是否变化。状态拆分：源端一个状态在目标端需要区分更细的阶段，要同步补充流转条件和权限。新增状态：目标端需要源端没有的状态，要写明新增理由、进入与退出条件、由谁维护。
流转条件与审批规则的改写要逐条记录。例如源端“金额大于阈值需二级审批”在目标端改为按角色审批，映射表中应写清原条件、新条件、差异原因和业务确认人。审批规则涉及合规要求时，改写方案需要业务与合规相关角色共同确认。
无法等价时按影响程度决策：影响过程连续性但可替代的，选择改写或重建并记录替代方案；不影响当前业务、历史数据仅需留档的，可以舍弃并在差异说明中写明影响范围。舍弃不等于删除记录，映射行保留，验证状态标记为“已舍弃”，便于切换后回溯。
试迁移与核验证据怎么留
映射表填完不等于可用，需要用试迁移验证。试迁移选取代表性工作流，覆盖主流程、异常分支和跨角色审批三类场景，数量不必多，但要能暴露状态衔接和权限边界的问题。
验证项按对象类型组织：状态验证看每个状态能否正常进入和退出；流转验证看关键路径与回退路径是否符合预期；字段规则验证看必填、默认值、联动是否生效；权限验证看不同角色在各状态下能看到和操作什么；自动化验证看触发条件和动作结果；接口验证看调用是否返回预期数据。
核验证据建议三类留存：配置对照（源端配置与目标端配置的并排截图或导出）、流转结果（试迁移工作项在各状态间的实际流转记录）、权限验证（不同角色账号的操作结果记录）。每条证据关联到映射表的对象ID，验证状态随之更新为“试迁移通过”或“已验证”。
试迁移发现的问题要闭环：登记问题、定位对应映射行、修改映射或调整目标端配置、重新验证、更新证据。问题未关闭的映射行不能进入切换清单。ONES 的迁移实践建议在正式迁移前确认数据范围、功能匹配和系统适配，并把迁移工具、原厂服务与分阶段切换结合使用，试迁移阶段的核验记录正是这些确认动作的落点。
切换、回退与停止条件
切换前要设定明确的通过标准，通常包括：纳入范围的映射行全部达到“已验证”或经确认的“已舍弃”；试迁移覆盖的关键路径与边界场景全部通过；未关闭问题清单为空或有经批准的挂起方案；回退方案与责任人已确认。
回退触发条件应提前写清，例如切换后关键流程无法推进、权限错配导致数据可见范围异常、自动化规则误触发影响业务。回退范围要区分整体回退与局部回退：局部回退针对单个工作流或单类对象，整体回退针对切换批次。每个触发条件对应判断人、判断时限和回退操作步骤。
无法映射的对象在切换前要有处置结论：挂起（暂不迁移，保留源端只读访问）、替代（用目标端其他机制承接并记录差异）、舍弃（业务确认不再需要）。挂起对象要指定后续处理时间点，避免长期悬空。
切换后的观察项包括关键流程的实际流转情况、用户反馈的权限与字段问题、自动化规则的执行记录。责任分工上，平台管理员负责配置类问题，业务负责人负责语义与流程类问题，迁移负责人汇总问题并决定是否触发回退。观察期结束且问题闭环后，映射表归档，作为后续变更的对照基线。
常见问题
映射表填完了，是不是就可以安排正式切换？
填完只代表映射行有了初稿，离切换还有两步。第一步是试迁移：选取覆盖主流程、异常分支和跨角色审批的代表性工作流，逐项验证状态进入退出、流转路径、字段规则、权限边界和自动化结果。第二步是问题闭环：试迁移发现的问题要定位到具体映射行，修改映射或调整目标端配置后重新验证。只有纳入范围的映射行达到“已验证”或经确认的“已舍弃”，未关闭问题清单为空或有经批准的挂起方案，才具备切换条件。
源端一个字段在目标端拆成两个字段，映射表怎么记？
把源字段拆成两行记录，分别对应目标端的两个字段，每行写明拆分规则，例如按取值区间区分或按来源团队区分。差异说明中要记录拆分后可能丢失的组合信息，以及业务方对该损失的确认结论。如果拆分后仍无法完整表达原语义，把映射类型标为改写，并写明降级方式和影响范围。拆分规则和确认人一并留痕，后续复核时能追溯判断依据。
迁移过程中源端配置又改了，映射表怎么跟？
这属于变更控制问题。输入材料进入版本冻结后，源端或目标端发生配置变更，应登记变更内容、变更时间、影响哪些映射行、由谁更新、是否需要重新核验。受影响的映射行验证状态回退到“待映射”或“已映射”，重新走验证流程。没有变更控制的映射表，在试迁移阶段往往已经和实际配置脱节，切换时容易出现配置与记录不一致的情况。
有些工作流暂时无法映射，切换时怎么处理？
切换前要给每个无法映射的对象一个处置结论，常见三种：挂起，暂不迁移并保留源端只读访问，同时指定后续处理时间点；替代，用目标端其他机制承接并记录差异；舍弃，业务确认不再需要，映射行保留并标记为“已舍弃”。挂起对象不能长期悬空，否则源端无法下线，迁移项目也难以收尾。处置结论由业务负责人确认，迁移负责人汇总进切换清单。
回退应该整体回退还是只回退出问题的工作流？
取决于问题范围。局部回退针对单个工作流或单类对象，适合某条流程无法推进、某类权限配置错配的情况；整体回退针对整个切换批次，适合多个关键流程同时受阻或出现数据可见范围异常。回退触发条件要提前写清，并为每个条件指定判断人、判断时限和回退操作步骤。回退范围越小，业务中断面越窄，但需要确认局部回退后源端与目标端并存期间的数据口径。
