Jira 历史记录迁移的关键，是把“历史”拆成可核对的对象：工单主记录、状态流转历史、评论与附件、字段变更记录、用户与权限引用。先盘点来源范围并冻结写入，再建立字段与状态映射表，用一小批工单试迁移，逐条比对数量、字段值、时间戳和附件完整性，通过后分批切换。本文按范围界定、前置准备、映射、试迁移、核验、回退六个阶段展开，并在映射与核验环节说明 ONES 可承载的相关能力。
要点总览（TL;DR）
- 先把“历史记录”拆成工单主记录、状态流转历史、评论与附件、字段变更记录、用户与权限引用五类对象，逐类标注完整迁移、仅保留摘要或归档不进入日常视图。
- 迁移前整理字段字典、状态与工作流清单、用户映射基础数据，并约定来源系统写入冻结窗口；冻结时长在试迁移结论出来后再定。
- 字段映射表逐行记录来源字段、目标字段、类型、取值转换规则、负责人和待确认项；同名字段先比对类型与取值集合，再抽样看实际填写内容，最后与实际使用方确认。
- 试迁移选几十到一两百条覆盖主要类型、状态和附件情况的样本，按用户、配置、主记录、评论附件的顺序执行，问题回写映射表后再决定是否全量。
- 核验按工单数、评论数、附件完整性、关键字段值、时间戳与状态顺序逐项比对并留存批次记录；数量差异无法解释、映射歧义未确认或附件缺失时停止当前批次，按影响范围选择单批或整体回退。
迁移范围：Jira 历史记录里哪些内容要迁
范围盘点决定后续所有工作量。第一步要写清四件事：来源是哪个 Jira 实例、版本与部署形态（Server、Data Center 或 Cloud）、涉及哪些项目与问题类型、目标系统及承载方式（自建或云端）。这些信息缺失时，映射和试迁移都缺少判断依据，因此应在盘点阶段就与管理员确认并记录。
“历史记录”本身是一个笼统说法，需要拆成可逐项核对的清单。建议按下表分类，并为每一类标注迁移取舍：完整迁移、仅保留摘要、或迁移后归档不进入日常视图。
| 对象类别 | 典型内容 | 取舍判断要点 |
|---|---|---|
| 工单主记录 | 标题、描述、类型、优先级、经办人、报告人、当前状态 | 通常完整迁移，是其他历史记录的挂载主体 |
| 状态流转历史 | 每次状态变更的时间、操作人、原状态与新状态 | 关注是否需要保留完整流转链，还是只保留当前状态与关键节点 |
| 评论 | 评论文本、作者、时间、可见范围 | 内部备注类评论是否随迁，需与业务方确认 |
| 附件 | 文件、图片、日志 | 关注总量、单文件大小上限与存储成本 |
| 字段变更记录 | 字段值修改的时间、修改人、旧值与新值 | 审计要求高的项目倾向完整保留，其余可只保留最终值 |
| 用户与权限引用 | 账号、用户组、项目角色、权限方案 | 需与目标系统的账号体系对齐，离职账号如何处理要提前定 |
取舍结论要落到具体项目，而不是笼统写“全部迁移”。例如某项目近三年工单完整迁移、更早工单只迁主记录与附件，这类边界写清楚，后续核验才有对照口径。若目标为 ONES，其 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并可从 Jira 迁移用户、用户组、问题类型、工作流、字段配置、权限配置以及问题属性、附件、评论等信息；具体范围仍以项目盘点结果为准，Jira 版本与部署形态的兼容情况需在启动前与实施方确认。
迁移前要准备什么：输入、依赖与冻结窗口
前置准备的目标是让迁移执行时不再临时找人、找权限、找口径。建议整理成一张核对表，逐项确认责任人和完成时间。
- 权限与配合：来源 Jira 的导出或读取权限、管理员账号配合事项、目标系统的建项目与建字段权限。缺少管理员配合时，字段配置和工作流迁移往往卡在第一步。
- 字段字典：导出各项目的字段清单，记录字段名称、类型、是否必填、可选值列表、在哪些界面出现。自定义字段是重点，同名不同义的情况多出现在这里。
- 状态与工作流清单：列出每个项目的工作流、状态集合、流转规则，标注哪些状态实际已停用但仍存在于历史数据中。
- 用户映射基础数据：来源账号列表、邮箱、所属用户组，以及目标系统的账号清单。先做一轮自动匹配，再人工处理匹配不上的账号。
- 冻结窗口：约定来源系统停止写入的时间段，以及冻结期间新工单如何登记（例如临时表格登记、迁移后补录）。冻结窗口长度取决于数据量和试迁移结论，不宜在未试迁移前拍定。
这张核对表同时是沟通工具：每一项标注“已确认、待确认、不适用”，迁移启动会前逐项过一遍，未确认项要么给出结论，要么明确不影响本批执行。
字段与状态映射：同名字段含义不同怎么处理
映射表是迁移质量的核心交付物。它至少要包含以下列，并且每一行都有负责人：
| 列名 | 填写内容 | 示例 |
|---|---|---|
| 来源字段 | Jira 中的字段名与类型 | “影响版本”，多选 |
| 目标字段 | 目标系统中的字段名与类型 | “影响版本”，多选 |
| 类型是否一致 | 一致、可转换、需拆分或合并 | 可转换 |
| 取值转换规则 | 枚举值对照、空值处理、超长截断规则 | “无”映射为空；历史版本名保留原文 |
| 负责人 | 对该字段口径负责的人 | 项目管理员 |
| 待确认项 | 尚未定论的问题及确认时间 | 旧版本名是否统一改名，待业务确认 |
同名字段含义不同，是映射中最容易出错的地方。判定方法可以分三步：先比对字段类型与可选值，类型不同或取值集合差异大时基本可判定为不同义；再抽样查看实际填写内容，例如来源系统的“优先级”只有三档而目标系统有五档，就需要定义档位对应关系；最后与字段的实际使用方确认，尤其是被用于报表筛选的字段，口径变化会直接影响历史报表的可比性。判定为不同义后，处理原则是优先保证语义正确，其次保证可查询：能一一对应的直接映射，一对多的拆分或合并要在映射表中写明规则，无法对应的值统一落到一个明确的“未分类”值，而不是随意丢弃。
状态与工作流的映射遵循同样思路。先列出源状态集合与目标状态集合，画出对应关系；当目标工作流的状态更少时，采用降级方案：多个源状态合并到一个目标状态，同时在工单描述或历史备注中保留原状态名称，避免信息完全丢失。当目标工作流更细时，不要凭空新增状态去承接历史，而是把无法判断的工单放在一个过渡状态，由业务方在迁移后按需调整。
映射歧义必须有记录和确认流程：任何一行映射在试迁移前处于“待确认”状态，就不应进入全量批次。确认流程可以很简单——映射表按项目分发给业务负责人，约定确认截止时间，确认结果回写到“待确认项”列并留痕。若目标为 ONES，其迁移方案包含字段配置与工作流的迁移，映射后的字段与状态可在 ONES Project 中承载；具体字段类型与工作流配置的对应细节，以实施时的实际盘点为准。
试迁移怎么做：小批量验证映射
试迁移的目的不是证明“能迁”，而是暴露映射表和执行流程中的问题。样本选取应覆盖主要工单类型、主要状态（包括已关闭和已停用状态）、带附件与不带附件的工单、评论较多的工单，以及字段填写较全和大量留空的工单。样本量不必大，几十到一两百条即可，但覆盖面要够，否则试迁移通过也说明不了问题。
执行顺序建议固定下来，便于复现：先迁用户与用户组，再迁项目与字段、工作流配置，然后迁工单主记录，最后迁评论、附件与历史记录。每完成一步记录开始时间、结束时间、处理条数和异常条数。异常不要当场手工修补，而是记录原始标识（如工单编号）和现象，统一回写映射表或执行脚本。
试迁移发现的问题分三类处理：映射规则问题回写映射表并重新确认；执行流程问题（如附件路径、编码、超时）调整操作步骤后重跑同一批样本；数据本身问题（如来源数据缺失、脏数据）单独列出清单，由业务方决定是修正来源数据还是接受现状。试迁移通过的判定口径建议在开始前就写明，例如：样本工单全部可查、字段映射无待确认项、数量与来源一致、附件可打开、状态流转顺序与来源一致。任一条不满足，就不进入全量。
核验与证据：数量、字段、时间与附件怎么比对
核验要回答“迁得对不对、少了什么、能不能追溯”。建议按以下清单逐项执行，并把结果记录到批次级别的核验表中。
| 核验项 | 比对方法 | 通过标准 |
|---|---|---|
| 工单数量 | 来源按项目、类型、状态分组计数，与目标同口径计数对比 | 分组数量一致，差异逐条说明原因 |
| 评论数量 | 按工单统计评论条数，汇总对比 | 总数一致，抽样工单逐条一致 |
| 附件数量与完整性 | 统计附件个数与总容量，抽样打开文件 | 数量一致，抽样文件可正常打开且内容一致 |
| 字段值 | 关键字段全量比对，其余字段抽样比对 | 关键字段无差异，抽样差异均有映射规则解释 |
| 时间戳与状态顺序 | 抽样工单核对创建时间、状态变更时间与顺序 | 时间与顺序与来源一致，时区口径统一 |
| 用户与权限引用 | 核对经办人、报告人、评论作者是否落到正确账号 | 无未匹配账号，或未匹配账号已列入处理清单 |
全量比对与抽样比对的选择取决于字段重要性：用于统计报表、考核或审计的字段做全量比对；描述性、自由文本类字段做抽样比对即可。时间戳核对要特别注意时区设置，来源与目标时区不一致时，先统一口径再比对，否则会把时区差异误判为数据错误。
证据留存的形式可以是一张按批次编号的核验表，附上计数脚本的输出、抽样工单清单和差异说明，每份记录标注执行人和复核人。证据的作用有两个：一是切换决策有依据，二是后续出现争议时能快速定位是迁移问题还是使用问题。若目标为 ONES，迁移后的工作项、字段值与评论可在 ONES Project 中直接查询比对，核验记录可作为项目文档留存；历史记录中时间戳与操作人的保留口径，建议在试迁移阶段就用样本确认，而不是等到全量后再发现差异。
回退与停止条件：哪些情况必须停下来
停止条件应在迁移开始前写进执行方案，而不是出问题时临时讨论。以下情况建议直接停止当前批次：数量差异超出约定阈值且无法解释；存在未确认的映射歧义却已进入执行；附件出现缺失或无法打开；用户映射出现大面积未匹配；目标系统出现影响数据写入的故障。
回退分两个层级。单批回退适用于某一批次数据异常、影响范围限于该批工单的情况：撤销该批写入，保留已通过批次，修正问题后重新执行该批。整体回退适用于映射规则本身存在系统性错误、或目标系统配置需要重做的情况：清空本次迁移写入的数据，回到迁移前状态。选择哪一层，取决于问题是否只影响局部数据、修正成本以及是否已对外通知切换时间。
回退后要同步恢复来源系统的写入，避免团队在冻结窗口内无处登记工单。恢复写入前确认回退已完成，防止两边同时产生新数据造成二次混乱。回退不是结束，而是复盘起点：记录触发停止的具体现象、根因、映射表或流程的修正内容，修正完成并重新通过试迁移后，再安排下一次迁移。把每次停止和回退都当作映射表的一次修订，下一批的通过率会明显提高。
常见问题
Jira 历史记录里的状态流转历史和字段变更记录，需要完整保留时间和操作人吗？
这取决于项目的审计与追溯要求，需要在范围盘点阶段就定下来，而不是迁移完再补。审计要求高的项目，建议完整保留每次状态变更的时间、操作人和原状态与新状态；一般项目可以只保留当前状态与关键节点，字段变更记录只保留最终值。
无论选哪种口径，都要在试迁移阶段用样本确认目标系统实际保留到什么程度。时间戳和操作人的保留细节，建议以实施时的实际盘点结果为准，并在核验表中写明本项目的取舍，避免全量迁移后才发现与预期不一致。
来源 Jira 和目标系统的状态数量不一致，历史工单怎么处理？
先列出源状态集合与目标状态集合，画出对应关系。目标状态更少时，把多个源状态合并到一个目标状态，同时在工单描述或历史备注中保留原状态名称；目标状态更细时，不要凭空新增状态去承接历史，把无法判断的工单放在一个过渡状态，迁移后由业务方按需调整。
合并或过渡的规则要写进映射表，并标注负责人。任何一行映射在试迁移前仍处于待确认状态，就不应进入全量批次。
试迁移样本要选多少条，覆盖哪些情况才算够？
样本量不必大，几十到一两百条即可，关键是覆盖面。至少要覆盖主要工单类型、主要状态（包括已关闭和已停用状态）、带附件与不带附件的工单、评论较多的工单，以及字段填写较全和大量留空的工单。
试迁移通过的判定口径要在开始前写明，例如样本工单全部可查、字段映射无待确认项、数量与来源一致、附件可打开、状态流转顺序与来源一致。任一条不满足，就不进入全量。
迁移过程中发现问题，什么情况下只回退当前批次，什么情况下整体回退？
单批回退适用于某一批次数据异常、影响范围限于该批工单的情况：撤销该批写入，保留已通过批次，修正问题后重新执行该批。整体回退适用于映射规则本身存在系统性错误、或目标系统配置需要重做的情况：清空本次迁移写入的数据，回到迁移前状态。
判断依据是问题是否只影响局部数据、修正成本，以及是否已对外通知切换时间。回退后先确认回退完成，再恢复来源系统写入，避免两边同时产生新数据。
迁移完成后，核验证据要留到什么程度才算可追溯？
建议按批次编号整理核验表，附上计数脚本输出、抽样工单清单和差异说明，每份记录标注执行人和复核人。用于统计报表、考核或审计的字段做全量比对，描述性、自由文本类字段做抽样比对即可。
时间戳核对要先统一时区口径再比对，否则会把时区差异误判为数据错误。证据的作用是让切换决策有依据，后续出现争议时能快速定位是迁移问题还是使用问题。
