Jira试迁移要验证的是映射规则能否跑通，样本选取应覆盖字段结构、流程结构和关系结构三类，每类取少量但形态齐全的数据，再补一组高频真实业务数据。样本量控制在可人工核对的范围，先确认字段含义、状态转换和关系链在目标平台能否正确落地，再考虑扩大数据量。本文按范围界定、样本选取、分批安排、输入准备、映射执行、核验留证和暂停回退七个环节展开。
要点总览（TL;DR）
- 试迁移的样本选取以结构覆盖为主：字段结构、流程结构、关系结构各取少量但形态齐全的数据，再补一组高频真实业务数据。
- 字段样本按类型逐一取样，重点覆盖带默认值、必填校验、多选项和含特殊字符或历史遗留选项的字段。
- 样本量控制在可人工逐条核对的范围，通常几十条高频数据足够；按风险排序分两批执行，第一批跑通映射规则，第二批验证修正后的稳定性。
- 核验按映射表逐行比对，失败项按字段类型、选项丢失、状态无法对应、关系链断裂等类别记录，并保留导入日志与比对截图。
- 字段含义无法对齐、权限或合规要求未满足、关系链断裂超出约定范围时，应暂停或回退映射规则，保持源数据不动、试迁移项目整体废弃重建。
试迁移的源与目标范围怎么定
试迁移的方向是单向的：从Jira读取数据，导入待选定的替代平台。源侧要记录Jira的版本与部署形态，Cloud和Data Center在导出方式、API权限和可用字段类型上存在差异，这些差异会直接影响样本能否顺利取出。目标侧要写明平台名称与版本，以及本次试迁移使用的项目空间。
对象范围建议按以下清单逐项勾选，形成一份范围说明：
| 范围项 | 纳入内容 | 说明 |
|---|---|---|
| 项目 | 1–2个有代表性的项目 | 优先选择字段配置和工作流较复杂的项目 |
| 问题类型 | 需求、任务、缺陷、子任务等常用类型 | 覆盖团队日常使用的主要类型 |
| 字段 | 系统字段与自定义字段 | 自定义字段按类型各取样本 |
| 工作流 | 典型状态、转换与条件 | 包含带条件或校验的转换 |
| 附件与评论 | 少量真实附件与评论 | 验证文件与富文本的落地效果 |
| 用户与权限 | 用户、用户组、权限方案 | 验证权限映射是否可执行 |
范围说明中要同时写明排除项，例如本次不迁移插件产生的自定义数据、不迁移看板配置、不迁移自动化规则。试迁移只做样本验证，不构成对全量迁移范围或迁移结果的承诺；全量阶段的对象清单需要在试迁移结论基础上另行确认。
代表性数据按哪几类结构选取
样本选取的核心是结构覆盖，而非数据量。字段、流程、关系三类结构决定了迁移映射的难度，每类都要取到形态齐全的样本，再叠加一组真实业务数据检验组合效果。
字段结构样本
自定义字段是映射问题最集中的地方。选取时按字段类型逐一取样：单行文本、多行文本、数字、日期、单选、多选、级联选择、用户选择器、复选框。每种类型至少取一个字段，并特别关注带默认值、必填校验和选项数量较多的字段。选项值本身也要检查，包含特殊字符、多语言或历史遗留选项的字段优先纳入。
流程结构样本
工作流样本要覆盖典型状态和转换，重点是带条件、校验器或后处理动作的转换。权限方案和通知配置也要取一组，验证目标平台能否表达相同的可见性规则。如果Jira中存在多个工作流或按问题类型区分的工作流，各取一个即可，不必穷举。
关系结构样本
关系数据容易被忽略，却直接影响迁移后的可用性。样本应包含：问题之间的链接（阻塞、关联、重复等类型）、子任务与父任务的层级、史诗与问题的归属、版本与修复版本的关联、附件、评论以及变更历史。选取一条关系链较长的问题作为重点样本，例如一个史诗下挂多个故事、故事再拆子任务并带附件和评论。
业务高频样本与边界样本
高频样本从真实项目中取团队最常创建的问题类型和典型数据量，用于检验映射规则在真实内容上的表现。边界样本单独准备：空值字段、超长文本、含特殊字符或表情的内容、多语言描述、已废弃但仍被引用的历史字段。这些数据往往在批量迁移时引发失败，提前在试迁移中暴露更划算。
| 结构类别 | 样本项 | 建议数量 | 选取理由 |
|---|---|---|---|
| 字段结构 | 各类型自定义字段 | 每类型1个，共8–12个 | 验证类型映射与选项转换 |
| 字段结构 | 带默认值、必填、多选项字段 | 3–5个 | 验证约束与默认值处理 |
| 流程结构 | 典型工作流及带条件转换 | 1–2条工作流 | 验证状态与转换映射 |
| 流程结构 | 权限方案与通知配置 | 1–2组 | 验证可见性规则表达 |
| 关系结构 | 问题链接、子任务、史诗归属 | 各2–3条链 | 验证关系链完整性 |
| 关系结构 | 附件、评论、历史记录 | 每条链若干 | 验证文件与富文本落地 |
| 业务高频 | 真实项目常见问题 | 20–50条 | 检验组合场景下的映射效果 |
| 边界 | 空值、超长、特殊字符、多语言 | 每类1–2条 | 提前暴露异常处理问题 |
样本量与优先级如何安排
样本量服从验证目标：结构样本优先于数据量，每类结构取少量但形态齐全，避免只取单一类型导致映射规则看似通过、实际遗漏分支。高频业务样本控制在可人工逐条核对的范围，通常几十条足够，数量再多会拉长核对周期而收益有限。
优先级按风险排序。字段含义存在歧义、流程分支复杂、关系链长的样本排在最前，因为这些位置一旦映射错误，修正成本最高。其次是权限与通知配置，最后是常规字段和大批量业务数据。建议分两批执行：第一批覆盖三类结构样本和边界样本，目标是跑通映射规则；第二批补充高频业务数据和第一批暴露问题的修正验证，用于确认规则稳定。
分批计划中要写明每批的样本范围、预期验证点和完成标志。第一批的完成标志是字段、状态、关系三类映射均有明确结论；第二批的完成标志是修正后的规则在真实数据上不再出现同类失败。
试迁移前需要哪些输入与依赖
执行前把输入备齐，能显著减少中途返工。需要准备的输入包括：
- Jira侧的导出权限与数据访问方式，确认账号能读取项目、字段配置、工作流和附件。
- 字段字典，逐项记录字段名称、类型、选项值、是否必填、默认值和使用该字段的问题类型。
- 工作流说明文档，标注状态、转换、条件和权限方案。
- 目标平台的字段类型与状态模型对照资料，用于判断哪些类型可以直接对应、哪些需要转换。
- 参与核对的业务方与负责人名单，明确谁对字段含义和流程规则做最终确认。
- 样本数据的脱敏与合规处理方案，涉及客户信息、个人信息的内容在导入前完成处理。
如果Jira中依赖插件实现定制字段或流程逻辑，需要单独列出并逐项评估，不能假设所有插件能力都能在目标平台找到对应实现。这份清单同时作为责任人分工表，每项输入标注提供人和确认人。
样本映射与试迁移怎么执行
执行顺序建议从字段到流程再到关系，逐层推进，每层确认后再进入下一层。
第一步做字段级映射：建立映射表，逐行记录Jira字段名称、类型、选项值、必填与默认值，以及目标平台对应的字段和转换规则。同名字段含义不同时以业务含义为准，例如Jira中的“优先级”在目标平台可能对应“严重程度”，映射表中要显式标注这种差异，避免按名称机械对应。
第二步做流程映射：列出状态对应关系、转换条件与权限规则，确认目标平台的状态模型能否表达相同的流转约束。无法直接表达的条件要记录为待确认项，由业务方判断是否可以简化。
第三步处理关系映射：链接类型、子任务层级、史诗归属、附件与评论。关系映射依赖前两步的字段和状态已经就位，否则导入后无法正确挂接。
映射表确认后，在目标平台建立独立的试迁移项目，导入样本数据。试迁移项目与正式项目隔离，便于整体废弃重建。以ONES为例，其Jira数据迁移覆盖用户、用户组和系统配置，以及项目、问题类型、工作流、字段配置、权限配置等，问题数据包括属性和属性值、附件、评论等信息；试迁移阶段可以借助这套迁移能力先导入样本，再对照映射表逐项检查落地结果。具体字段类型的对应关系仍需在试迁移中验证，不能预先假设全部一致。
核验与证据怎么留
核验按映射表的行逐项进行：字段值是否正确、选项是否完整、必填与默认值是否生效、状态与转换是否符合预期、关系链是否完整。除逐项核对外，再抽取若干关键问题做源与目标的人工比对，重点看长文本、附件和评论的呈现效果。
失败项要记录并分类，常见类别包括：字段类型不支持、选项值丢失、状态无法对应、关系链断裂、附件或评论缺失、权限规则无法表达。分类的目的是让修正动作有明确指向，而不是笼统记为“迁移失败”。
证据留存包括导入日志、源与目标的比对截图、核验结论和失败项清单。核验报告的结构建议为：通过项、失败项及原因分类、修正建议、业务方确认意见。报告由业务方签字确认样本可用性，作为是否进入下一批或全量阶段的依据。
哪些情况应暂停或回退
试迁移阶段设置明确的停止条件，比事后补救更有效。以下情况应暂停推进：字段含义无法对齐且业务方无法给出确认意见；权限或合规要求未满足，例如脱敏不彻底或权限方案无法在目标平台表达；关键业务字段在目标平台没有可接受的承载方式。
以下情况应回退映射规则：关系链断裂比例超出事先约定的可接受范围；状态转换在目标平台产生与源系统明显不同的业务后果；批量导入后出现系统性字段错位。回退时保持源数据不动，试迁移项目整体废弃重建，修正映射表后重新选取样本验证，避免在错误数据上反复修补。
停止与回退条件清单要与核验报告联动：每个失败项分类对应一个处理动作，是修正映射、更换样本还是升级为范围调整，由项目负责人和业务方共同决定。试迁移的结论只对已验证的样本范围负责，全量迁移的范围与风险需要在此基础上重新评估。
常见问题
Jira试迁移只取少量数据，会不会漏掉全量迁移才会出现的问题？
试迁移的目标是验证映射规则能否跑通，样本量按结构覆盖来定，不追求数据量。字段、流程、关系三类结构各取形态齐全的样本，再补几十条高频真实数据，足以暴露类型映射、选项转换、状态对应和关系挂接的主要问题。
试迁移结论只对已验证的样本范围负责。全量阶段的数据规模、插件定制和异常数据，需要在试迁移结论基础上重新评估范围与风险，不能把样本通过直接当成全量可迁移的结论。
Jira Cloud 和 Data Center 的试迁移样本选取有区别吗？
两种部署形态在导出方式、API 权限和可用字段类型上存在差异，这些差异会影响样本能否顺利取出。试迁移范围说明中应记录源侧的版本与部署形态，再据此确认导出通道和可读取的对象。
如果团队同时存在两种形态的 Jira 实例，建议分别取样验证，不要用其中一个实例的结论直接套用到另一个。
依赖插件实现的自定义字段和流程逻辑，试迁移时怎么处理？
插件产生的定制字段和流程逻辑需要单独列出并逐项评估，不能假设所有插件能力都能在目标平台找到对应实现。样本选取时把这类字段和转换标记出来，在映射表中记录其业务用途，由业务方判断能否用目标平台的原生能力替代或简化。
无法替代的部分应记录为待确认项，作为范围调整的依据，而不是在试迁移中强行映射。
试迁移需要重复导入多次，样本怎么安排比较合适？
建议分两批：第一批覆盖三类结构样本和边界样本，目标是跑通映射规则；第二批补充高频业务数据，并验证第一批暴露问题的修正效果。
试迁移项目与正式项目隔离，修正映射表后可整体废弃重建再导入，避免在错误数据上反复修补。每批开始前明确样本范围和完成标志，第一批的完成标志是字段、状态、关系三类映射均有明确结论。
业务方在试迁移中需要确认什么？
业务方主要确认两件事：字段的业务含义是否与目标平台的字段一致，以及状态转换后的业务后果是否符合预期。同名字段含义不同时，以业务含义为准建立映射，由业务方给出确认意见。
核验报告完成后，由业务方确认样本可用性，作为是否进入下一批或全量阶段的依据。字段含义无法对齐且业务方无法确认时，应暂停推进。
