试迁移跑完并不等于可以正式切换，关键在于把迁移结果转成一套可复算的验收标准：先界定评估范围与样本，再为每类对象定义分子、分母和时间窗，最后按数据完整性、业务可用性、用户验证、回退可行性四步逐项判定。本文给出一套适用于Jira替换场景的判定方法，包含指标口径表、结论分级规则和一个可复算的算例，阈值需由组织结合自身风险约定，不套用通用达标线。
要点总览（TL;DR）
- 试迁移结果要转成可复算的验收标准：先界定样本项目与高风险对象，再为每类指标写明分子、分母和时间窗，最后按数据完整性、业务可用性、用户验证、回退可行性四步判定。
- 数据完整性、权限正确性和回退可行性必须由试迁移给出明确结论；用户习惯、报表样式、非关键集成性能可留到切换后观察期跟踪。
- 分母为零统一记为“不适用”并单列，不能因为“没有失败”就视为通过；字段类型变化、状态重映射等不可比对象改为人工抽检。
- 结论分为通过、有条件通过、不通过三类：硬性项出现阻断级差异或回退演练失败即不通过；个别软性项未达阈值但不影响核心业务，可列为有条件通过并约定复测。
- 试迁移达标只说明样本范围内具备切换条件，阈值由组织按风险约定，切换后仍需设置观察期跟踪数据一致性、用户问题与集成调用情况。
试迁移要回答的切换问题与验收目标
试迁移的价值在于产出决策证据，而非把迁移流程走一遍。它要回答的核心问题是：在受控的样本范围内，迁移后的数据、配置、权限、集成和用户操作能否支撑业务继续运转，以及一旦出现问题能否退回。把这个问题拆开，就得到五类判定对象和对应的验收目标。
| 判定对象 | 验收目标 | 支撑的切换决策 |
|---|---|---|
| 数据 | 工作项条数、字段值、附件、评论、状态历史在迁移前后一致 | 是否具备全量迁移的数据基础 |
| 配置 | 问题类型、工作流、字段配置在目标系统中可用且行为符合预期 | 业务流程能否原样承接 |
| 权限 | 用户、用户组与权限方案迁移后，可见范围与操作权限符合预期 | 是否存在越权或失权风险 |
| 集成 | 依赖Jira的外部系统调用在目标系统上可正常完成 | 周边工具链是否需要同步改造 |
| 用户操作 | 关键角色按真实任务走通日常操作 | 团队能否在切换后立即恢复协作 |
这些目标中，数据完整性、权限正确性和回退可行性必须由试迁移给出明确结论，因为它们一旦在正式切换后暴露，修复成本高且影响面大。用户操作习惯类问题、个别报表样式差异、非关键集成的性能表现，可以留到正式切换后的观察期继续跟踪，不必作为切换的前置阻断项。把这两类结论分开，能避免试迁移被无限期拉长。
评估范围与样本选择：哪些项目和数据算数
用几个结构简单的项目跑通迁移，无法推断全量切换可行。样本选择要按复杂度分层，确保高风险对象至少被覆盖一次。
建议按四个维度分层抽取项目：项目规模（工作项数量从少到多）、自定义字段复杂度（字段数量与字段类型，尤其是级联选择、多选、公式类字段）、工作流分支（是否存在多条件分支、跨项目状态流转）、附件量（大附件、特殊格式附件）。每一层至少选一个项目，规模最大和字段最复杂的项目应优先纳入。
必须覆盖的高风险对象包括：自定义字段及其历史值、状态流转历史、权限方案（含项目角色与问题级安全级别）、自动化规则（如状态变更触发通知或字段赋值）、外部集成（代码仓库关联、持续集成回调、单点登录等）。这些对象在迁移中最容易出现“结构迁过去、行为对不上”的情况。
| 覆盖项 | 样本项目 | 覆盖对象 | 未覆盖部分及处理 |
|---|---|---|---|
| 大规模项目 | 项目A（工作项最多的项目） | 工作项、评论、附件、状态历史 | 归档项目不纳入，标注为切换后抽检 |
| 复杂字段项目 | 项目B | 自定义字段及历史值 | 低频字段标注为切换后验证 |
| 多分支工作流项目 | 项目C | 工作流、自动化规则 | 跨项目流转场景标注为切换后验证 |
| 集成密集项目 | 项目D | 代码仓库关联、回调接口 | 非关键集成标注为观察项 |
未纳入试迁移的范围不能默认安全，应逐项登记为切换后风险，写明风险描述、影响范围和计划验证时间。这份清单本身就是切换决策的输入之一：未覆盖项越多、越靠近核心业务，正式切换的把握就越需要打折。
指标与数据口径：分子、分母和时间窗怎么定
指标要能复算，就必须写清分子、分母、统计时间窗和单位。同一份试迁移结果，分母取“样本全部记录”还是“存在该类数据的记录”，结论可能完全不同，因此口径要在计算前固定下来。
| 指标 | 公式 | 分母定义 | 时间窗 | 缺失值处理 |
|---|---|---|---|---|
| 记录条数一致率 | 迁移后条数 ÷ 迁移前条数 × 100% | 迁移前该项目的全部工作项数 | 迁移完成时点快照 | 迁移前为零的项目记为不适用 |
| 字段非空完整率 | 迁移后非空值数 ÷ 迁移前非空值数 × 100% | 迁移前该字段非空记录数 | 迁移完成时点快照 | 迁移前全为空的字段记为不适用，不计入通过率 |
| 附件可打开率 | 可正常打开附件数 ÷ 迁移附件总数 × 100% | 迁移前附件总数 | 迁移完成后3个工作日内抽检 | 无附件的项目记为不适用 |
| 状态与历史一致率 | 状态及流转历史一致的工作项数 ÷ 抽检工作项数 × 100% | 抽检工作项数（按分层抽样确定） | 抽检执行期间 | 无历史记录的工作项不纳入抽检 |
| 关键工作流可走通率 | 走通的关键流程数 ÷ 计划验证的关键流程数 × 100% | 计划验证的流程清单条数 | 用户验证阶段 | 流程清单为空时判定为验证未执行，不记为通过 |
| 权限符合预期比例 | 权限符合预期的角色数 ÷ 验证的角色数 × 100% | 验证的角色清单条数 | 用户验证阶段 | 未验证角色不计入分母，单独列为未覆盖项 |
| 集成调用成功率 | 成功调用次数 ÷ 总调用次数 × 100% | 验证期间实际发起的调用次数 | 连续3个工作日 | 调用次数为零记为不适用，需说明原因 |
分母为零的处理规则要事先约定，统一记为“不适用”，并在结论中单列，不能因为“没有失败”就视为通过。例如某项目没有附件，附件可打开率不适用，这不构成附件迁移能力的证据，附件能力应由其他有附件的样本项目来证明。同理，如果所有样本项目都没有使用某类自定义字段，那么该类字段的迁移质量在试迁移中实际未被检验，应转入未覆盖风险清单。
数据不可比的情况也要提前说明：迁移前后字段类型发生变化（如单选改为多选）、状态名称被重新映射、附件存储路径调整，都会让简单比对失真。这类对象应改为人工抽检并记录判定依据，而不是硬套百分比。
判定步骤：从原始结果到切换结论
指标算完后，按固定顺序汇总，避免用某一项高分掩盖另一项阻断问题。
第一步，核对数据完整性硬性项。检查记录条数一致率、状态与历史一致率、附件可打开率。出现阻断级差异，例如整批工作项缺失、状态历史断裂、附件大面积无法打开，直接判定不通过并停止后续评估，先修复再重跑试迁移。阻断级的标准由组织约定，但应在试迁移开始前写明。
第二步，计算业务可用性指标并与阈值比对。关键工作流可走通率、权限符合预期比例、集成调用成功率逐项对照约定阈值。这一步的产出是“达标项”和“未达标项”两张清单，未达标项要写明影响范围和初步原因。
第三步，组织关键用户按真实任务验证。让开发、测试、项目管理者分别用迁移后的数据完成一次日常任务，例如创建并流转一个工作项、查询历史版本、按权限查看受限内容。问题按等级记录：阻断业务的问题、影响效率的问题、体验类问题。问题清单需要有承载和跟踪的载体，ONES可用于承载试迁移中发现的缺陷、整改项与复测任务，把每个问题对应到责任人和复测时间，便于在结论评审时逐条核对关闭状态。
第四步，演练回退。在试迁移环境中执行一次完整回退，记录回退耗时、数据可恢复程度、回退后原系统是否可正常使用。回退演练未成功，即使前三步全部达标，也不具备正式切换条件。
| 结论 | 判定条件 | 后续动作 |
|---|---|---|
| 通过 | 硬性项全部通过，软性项达到约定阈值，回退演练成功 | 进入正式切换排期 |
| 有条件通过 | 硬性项通过，个别软性项未达阈值但不影响核心业务，回退演练成功 | 列明整改项、责任人与复测要求，复测通过后切换 |
| 不通过 | 出现阻断级数据差异，或回退演练失败，或多项软性指标显著偏离 | 修复问题后重新组织试迁移 |
算例：一个试迁移批次的判定过程
以下为演示情景，数据为假设值，用于说明计算与判定过程。
某团队选取4个项目做试迁移，迁移前工作项合计12,000条，迁移后11,988条，记录条数一致率为11,988 ÷ 12,000 = 99.9%，缺失12条集中在项目C的已关闭工作项，经核查为状态映射规则遗漏，属于可定位、可修复的差异，未达到阻断级。
字段完整率按字段逐个计算：项目A的“客户编号”字段迁移前非空记录800条，迁移后非空796条，完整率99.5%；项目B的“需求来源”字段迁移前全部为空，记为不适用，不参与通过率统计；项目D的“合同金额”字段迁移前非空300条，迁移后非空240条，完整率80%，低于约定的95%阈值，列为未达标项。
附件方面，迁移附件共2,400个，抽检可打开2,388个，可打开率99.5%；无法打开的12个均为特殊格式文件，已登记为问题。状态与历史一致率按抽检600个工作项计算，一致582个，为97%，未达约定的99%阈值，问题集中在跨项目流转的历史记录。
业务可用性方面，计划验证关键流程10条，走通9条，可走通率90%；验证角色8个，权限符合预期7个，比例87.5%；集成调用在3个工作日内共发起500次，成功485次，成功率97%。回退演练完成，回退耗时与数据恢复情况记录在案，满足组织约定。
综合判定：硬性项中记录条数、附件可打开率通过，状态与历史一致率未达阈值但差异可定位；软性项中字段完整率、权限符合预期比例、集成成功率各有未达标项，均不影响核心业务走通。结论为“有条件通过”，整改项包括：修复项目C状态映射规则并复测12条缺失工作项、补齐项目D合同金额字段的迁移逻辑、核查跨项目流转历史记录、处理12个特殊格式附件。复测要求为整改完成后对上述四项重新计算对应指标，全部达到约定阈值方可进入正式切换排期。
结果解读与限制：哪些结论不能从试迁移得出
试迁移达标说明样本范围内迁移质量可接受，它不构成正式切换后无风险的保证。解读结果时有三条边界需要守住。
第一，样本偏差客观存在。试迁移项目经过挑选，规模和复杂度通常低于全量项目集合，未纳入的项目中可能存在更复杂的字段组合、更长的状态历史或更特殊的集成方式。因此结论应表述为“样本范围内具备切换条件”，全量切换前仍需对未覆盖项安排抽检。
第二，指标达标与业务效果是两件事。迁移成功率、字段完整率反映的是数据搬运质量，不能直接当作团队效率提升或管理改善的绩效结论。切换后业务是否顺畅，还取决于培训、流程调整和使用习惯，需要单独观察。
第三，阈值是组织约定，不是行业标准。记录条数一致率定99.9%还是99%，取决于业务对数据缺失的容忍度；附件可打开率是否要求100%，取决于附件在业务中的使用强度。照搬其他团队的达标线，可能把风险定得过松或过紧。
正式切换后建议设置观察期，持续跟踪以下项目：数据一致性抽检结果、用户提交的问题数量与等级分布、集成调用成功率、关键流程的平均处理时长。观察期内出现集中性问题，应及时启动预案，而不是等到问题累积后再处理。回退方案在切换后的一段时间内也应保持可用，具体保留时长由组织根据业务连续性要求确定。
常见问题
试迁移中某个指标分母为零，应该算通过还是不通过？
都不算。分母为零说明该类数据在样本中不存在，指标实际未被检验，应统一记为“不适用”并在结论中单列。例如所有样本项目都没有使用某类自定义字段，那么该类字段的迁移质量在试迁移中没有得到验证，应转入未覆盖风险清单，安排正式切换前补测或切换后抽检。
把“不适用”当作通过，会让结论虚高；直接判不通过，又会因为样本选择问题卡住整个项目。正确做法是记录不适用原因，并确认该能力是否由其他样本覆盖。
硬性项和软性项如何划分，阈值由谁定？
硬性项通常包括记录条数一致率、状态与历史一致率、附件可打开率以及回退演练结果，它们一旦在正式切换后暴露，修复成本高、影响面大。软性项包括字段完整率、权限符合预期比例、集成调用成功率等，未达标时可通过整改和复测收敛。
具体阈值没有通用标准，应由组织在试迁移开始前结合业务对数据缺失的容忍度约定，并写入验收方案。阈值定得过松会放大切换风险，定得过紧则可能让可修复的问题阻断排期。
试迁移发现问题后，整改和复测怎么跟踪才不会遗漏？
关键是让每个问题都有责任人和复测时间，并在结论评审时逐条核对关闭状态。可以把问题按阻断业务、影响效率、体验类分级，整改项与复测任务放在同一处跟踪，避免散落在聊天记录或表格里。
ONES 可用于承载试迁移中发现的缺陷、整改项与复测任务，把问题对应到责任人和复测节点。复测时对原指标重新计算，达到约定阈值后再进入正式切换排期。
试迁移全部指标达标，是否就可以直接安排正式切换？
还需要确认两件事：回退演练是否成功，以及未覆盖范围的风险是否可接受。回退演练未成功，即使数据指标全部达标，也不具备正式切换条件。
另外，试迁移项目经过挑选，规模和复杂度通常低于全量项目集合。结论应表述为“样本范围内具备切换条件”，对未纳入试迁移的归档项目、低频字段、跨项目流转场景安排抽检计划，再确定切换窗口。
原来依赖 Jira 插件的功能，试迁移阶段要怎么验证？
先梳理实际在用的插件及其承担的业务动作，再逐项确认目标系统上由什么能力承接。ONES 的建议是先梳理插件使用情况，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配；企业已有的定制场景在迁移前仍需逐项评估，不能假设所有插件都能一一对应。
试迁移阶段可以把插件相关场景列入高风险对象，按真实任务走通一次，走不通的登记为整改项或切换后风险，而不是留到正式切换后再发现。
