迁移能力等价性评审要回答的是一个具体问题：源平台上支撑业务运转的工作流、扩展机制和协作行为，换到目标平台后还能不能按原有方式完成。它适用于工具切换前的方案确认阶段，产出的是带证据的结论和改造清单，而非功能对照表。本文按“圈范围—定标准—逐项取证—分工签字—收口检查”的主线展开，给出可直接套用的步骤、角色表和检查清单。
要点总览（TL;DR）
- 评审范围从业务场景出发：先按业务关键度和使用频率筛出关键场景，再把场景拆成能力项，并划清行为与能力迁移、记录数据搬运、目标平台日常配置三类边界。
- 判定口径要在逐项评审前统一：等价、可替代、需改造、不可迁移四类结论各有定义和证据门槛，操作路径变化归入可替代而非等价。
- 单条能力项按“拆解到可观察行为—两侧分别取证—记录差异并写改造方案—归档复核”四步推进，每条结论都要有可被第三方复核的证据。
- 结论由业务负责人与平台管理员共同确认，迁移负责人核对证据完整性，评审主持人做最终确认；争议按补充证据复评、主持人裁定、业务决策逐级升级。
- 评审收口需同时满足覆盖度、证据完整性、遗留项处置三项检查，遗留项纳入工作项跟踪并在改造完成后回填验证结果。
评审范围怎么定：先圈场景再列能力项
评审范围从业务场景出发，不从平台功能菜单出发。把源平台的全部功能平铺成清单，会得到几百条无法排序的条目，评审精力被大量低频配置消耗，真正影响交付节奏的场景反而评得不深。合理的顺序是先按业务关键度和使用频率筛出场景，再把场景拆成能力项。
筛选待评场景的两个维度
业务关键度看该场景中断后对交付、合规或客户承诺的影响；使用频率看单位时间内实际发生的次数和涉及人数。两个维度都高的场景优先纳入，例如每日运行的缺陷流转、每周执行的发布审批。关键度高但频率低的场景同样要评，例如季度性的合规归档流程，它一旦缺失，问题往往在审计时才暴露。频率高但关键度低的场景可以抽样评，用少量样本确认行为一致即可。
划清三类边界
评审开始前要明确哪些内容进本文的评审范围，哪些交给其他工作流处理，避免同一件事被重复评或漏评：
| 类别 | 典型内容 | 处理方式 |
|---|---|---|
| 行为与能力迁移 | 工作流状态与流转条件、字段联动与校验、自动化规则、权限与可见性、通知与协作行为、扩展插件承担的职能 | 本文评审对象，逐项给出四类结论 |
| 记录数据搬运 | 历史工作项、附件、评论、字段值的迁移与映射 | 归研发数据迁移与映射，本文只确认迁移后行为是否可用 |
| 目标平台日常配置 | 新平台的组织结构、项目模板、常规权限体系的日常维护 | 归研发平台业务配置与治理，本文只评迁移所需的配置是否到位 |
形成两份初稿
第一份是关键场景清单，每条包含场景名称、所属业务、关键度与频率判断、涉及角色、纳入理由。第二份是能力项清单初稿，从场景中拆出，每条能力项标注所属场景、源平台承载方式（原生功能、配置、插件或脚本）、初步风险判断。两份清单在评审启动会上过一遍，确认无遗漏后冻结版本，后续新增条目走变更记录。
等价性判定标准与四类结论
判定标准要在逐项评审开始前统一确认，否则不同评审人对同一条能力项会给出不同结论，评审记录失去可比性。统一的做法是先定义四类结论，再为每类结论规定证据门槛，最后由业务、平台和迁移三方在启动会上共同签字确认这套口径。
四类结论的定义与证据要求
| 结论 | 定义 | 证据要求 |
|---|---|---|
| 等价 | 目标平台以原生方式实现同一行为，触发条件、执行结果和可见范围与源平台一致 | 两侧配置截图或导出、同一输入下的结果对照记录 |
| 可替代 | 实现机制不同，但通过目标平台的其他原生能力组合可达成同一业务结果，使用者的操作路径有变化 | 替代方案说明、按替代方案走通的测试记录、对操作路径变化的确认 |
| 需改造 | 目标平台无法直接支撑原行为，需要配置调整、流程重设计或轻量开发才能满足 | 差异描述、改造方案、影响范围、责任人与预计完成时间 |
| 不可迁移 | 目标平台不具备对应机制，且改造代价超出可接受范围，业务需放弃或另行处理该行为 | 不可行的判断依据、业务影响说明、业务负责人的处置确认 |
统一口径的三个动作
第一，把“等价”的边界写清楚：结果一致但操作步骤不同，归入可替代而非等价，避免把操作变化掩盖成完全一致。第二，规定证据的最低形式，例如截图需包含配置入口与生效结果，测试记录需写明输入、预期与实际。第三，约定争议处理规则：评审人对结论有分歧时，先补充证据再复评，仍不一致则提交评审主持人裁定并记录理由。
逐项评审的操作步骤与取证方法
单条能力项的评审是一个固定动作序列，每一步都有输入、动作、输出和完成标志，按序执行可以保证记录可复核。
第一步：拆解到可观察行为
输入是能力项清单中的一条条目，动作是把它拆成“谁在什么条件下做什么、系统产生什么结果”。例如“审批流”这条过于笼统，拆解后应得到：提交人在什么状态下发起、审批人如何被确定、驳回后回到哪个状态、超时如何处理、结果通知给谁。输出是行为描述列表，完成标志是每条行为都能被单独观察和取证。
第二步：两侧分别取证
在源平台按行为描述逐条操作或导出配置，记录实际表现；在目标平台用同一组输入复现，记录结果。证据形式包括配置截图、导出文件、操作录屏和测试记录，每条证据标注采集人、采集时间和对应行为。完成标志是每条行为在两侧都有对应证据，缺失的一侧要注明原因。
第三步：记录差异并编写改造方案
把两侧证据逐条对照，差异写入差异记录，字段包括差异描述、影响范围（涉及哪些角色和场景）、初步结论。对判定为需改造的条目，补充改造方案：改造内容、实现方式、责任人、预计完成时间、验证方法。完成标志是每条差异都有结论，需改造项都有方案和责任人。
第四步：归档与复核
评审记录按场景归档，与能力项清单建立对应关系。复核由未参与该条取证的人员执行，核对证据是否支撑结论、改造方案是否可验证。复核通过后记录状态置为已确认，未通过则退回补充。完成标志是全部条目处于已确认或已升级状态，无悬空记录。
当评审条目达到数十条以上，记录分散在文档和表格里容易失去状态跟踪。这类评审记录、差异项和改造任务可以放进工作项中管理：每条能力项作为一个工作项，携带结论、证据附件、责任人和截止时间，改造任务作为关联项推进，评审主持人按状态视图检查进度。ONES 的项目与工作项机制可以承载这类跟踪，使评审结论与后续改造保持同一份记录。
角色分工与各环节交付物
评审要落到人头上才有约束力。以下四类角色覆盖从圈范围到签字的全过程，每个角色都有明确的输入和输出。
| 角色 | 主要职责 | 输入 | 输出交付物 |
|---|---|---|---|
| 业务负责人 | 判断场景关键度，确认业务结果是否可接受，对不可迁移项做处置决定 | 业务场景说明、现有流程文档 | 关键场景清单确认、不可迁移项处置意见 |
| 平台管理员 | 提供源平台配置与扩展机制说明，在目标平台完成配置与取证 | 能力项清单、行为描述 | 两侧配置证据、可替代方案说明 |
| 迁移负责人 | 组织评审节奏，汇总差异，编写改造方案并跟踪落地 | 差异记录、证据材料 | 差异改造清单、评审记录归档 |
| 评审主持人 | 主持口径确认与结论裁定，对争议项做最终判定 | 判定标准草案、争议记录 | 判定标准确认记录、裁定意见 |
签字确认与争议升级
每条能力项的结论由业务负责人与平台管理员共同确认，迁移负责人核对证据完整性后签字，评审主持人对整份评审记录做最终确认。争议升级路径为：评审人分歧→补充证据复评→评审主持人裁定→涉及业务取舍的提交业务负责人决策。每次升级都记录在案，包括分歧点、各方意见和最终依据。
示例：一条审批工作流的等价性评审记录
以下为演示情景，用于说明一条记录如何填写，不指向任何具体产品的实际配置。
能力项拆解与取证
能力项：需求变更审批流。拆解为四条可观察行为：变更单提交后进入待审状态；审批人按变更影响范围自动确定；驳回后回到草稿并通知提交人；审批通过后同步更新关联需求的状态。源平台取证：导出工作流配置，录屏演示一次提交、驳回、再提交、通过的全过程。目标平台取证：按同一组输入复现，记录审批人确定规则和状态联动结果。
判定结论及依据
前三条行为在目标平台以原生工作流实现，触发条件与结果一致，判定为等价，证据为两侧配置截图与操作录屏。第四条行为中，目标平台的状态联动需要额外配置规则才能实现，判定为需改造，依据是复现时关联需求状态未自动更新，差异记录中写明影响范围为所有涉及需求变更的项目。
改造方案与责任人
改造内容：在目标平台配置状态联动规则，使审批通过事件触发关联需求状态更新。实现方式：使用平台自动化规则配置，无需开发。责任人：平台管理员。预计完成时间：评审确认后一周内。验证方法：按原测试用例复跑，确认关联需求状态同步更新，并留存测试记录。该条目在改造完成并复核通过前，评审记录状态保持为待验证。
完成检查：评审可以收口的条件
评审能否作为切换决策依据，取决于三项检查是否同时满足。任一项不满足，评审记录只能标记为阶段性完成。
覆盖度检查
- 关键场景清单中的每个场景至少有一条能力项记录，且均有结论
- 高频场景已完成抽样评审，样本覆盖主要分支路径
- 评审期间新增的场景或能力项已走变更记录并完成评审
证据检查
- 每条结论都有对应证据，证据可被第三方复核
- 证据标注了采集人、采集时间和对应行为
- 可替代结论附有走通替代方案的测试记录
遗留项检查
- 需改造项均有改造方案、责任人和预计完成时间
- 不可迁移项均有业务负责人的处置确认
- 所有遗留项已纳入工作项跟踪，状态可查
三项检查全部通过后，由评审主持人签署评审结论，连同能力项清单、差异改造清单和证据材料一并归档，作为切换决策的输入。遗留项在改造完成后需回填验证结果，评审记录随之更新为最终状态。
常见问题
评审条目很多时，记录和改造任务怎么跟踪才不丢状态？
条目达到数十条以上时，文档和表格容易失去状态跟踪。可以把每条能力项作为一个工作项，携带结论、证据附件、责任人和截止时间，改造任务作为关联项推进，评审主持人按状态视图检查进度。ONES 的项目与工作项机制可以承载这类跟踪，使评审结论与后续改造保持同一份记录。关键是每条记录只有一个当前状态，避免文档版本与表格版本并存。
源平台用了插件或自定义脚本实现的能力，评审时怎么处理？
先把插件或脚本承担的实际职能拆成可观察行为，再在目标平台寻找原生能力组合或自动化规则来承接，按四类结论判定。ONES 的迁移建议是先梳理实际使用的插件，再通过项目、Wiki、测试用例、流程自动化和开放能力进行功能匹配；对企业已有的定制场景，迁移前仍需逐项评估，不能直接假设所有插件都能一一对应。判定为需改造的条目要写明改造方式、责任人和验证方法。
评审结论出现分歧时，按什么顺序处理？
分歧先回到证据：由持不同意见的评审人各自补充配置截图、测试记录或操作录屏，再复评一次。仍不一致的，提交评审主持人裁定，裁定意见连同各方理由一并记录。涉及业务取舍的，例如某能力判定为不可迁移后业务如何处置，提交业务负责人决策。每次升级都记录分歧点、各方意见和最终依据，保证后续复核可追溯。
评审通过后，需改造项还没完成，能不能先切换？
这属于切换决策问题，评审记录本身只提供依据。可行的做法是把需改造项按影响范围排序：影响核心交付流程的，改造完成并复核通过后再切换；影响范围有限且有临时替代路径的，可以在记录中写明临时方案、责任人和完成时间后分阶段切换。ONES 的迁移方案也建议把迁移工具、原厂服务和分阶段切换结合，并在正式迁移前确认数据范围、功能匹配和系统适配。无论哪种安排，遗留项都要保持可查状态，改造完成后回填验证结果。
历史数据和配置的迁移要不要放进等价性评审？
等价性评审的对象是行为与能力，历史工作项、附件、评论、字段值的搬运与映射归研发数据迁移与映射处理。评审中只需要确认迁移后行为是否可用，例如字段值搬过来后联动规则是否仍然生效。目标平台的组织结构、项目模板和常规权限体系的日常维护归研发平台业务配置与治理，评审只确认迁移所需的配置是否到位。这样划分可以避免同一件事被重复评或漏评。
