Jira 历史记录迁移的关键，是先界定哪些问题、评论、附件和变更记录必须保留，再建立用户、状态、字段、附件四类映射规则，通过小批量试迁核对数量与内容，确认后才分批切换。本文按盘点范围、建立映射、执行迁移、核验证据、停止与回退五个阶段展开，适用于已确定目标系统、准备把 Jira 项目数据搬过去的团队。
要点总览（TL;DR）
- 先盘点 Jira 项目中的问题、评论、附件、状态变更与经办人变更记录，按必须保留、可摘要保留、可丢弃三档确定范围，并由业务方确认。
- 迁移前完成用户、状态与工作流、字段、附件与富文本四类映射表，非一一对应的值写明归并或转换规则，不默认丢弃。
- 执行顺序为先主数据后问题与历史记录，按项目或时间分批，每批记录批次号与数量，用来源 ID 对照表支持中断续跑与去重。
- 核验采用数量比对加抽样内容比对，抽样覆盖不同项目、首尾状态与最早最晚记录，差异登记后决定补迁、接受或降级。
- 迁移前约定停止阈值与按批次的回退点，切换前由业务方确认范围、数量、抽样与差异处理全部通过。
迁移范围：Jira 里哪些历史记录需要搬
迁移范围从 Jira 项目和问题出发，落到目标系统的项目与工作项。盘点时按对象逐项列出，而不是笼统地说“把数据搬过去”。一份可用的来源对象清单至少覆盖六类内容：问题本身（标题、描述、类型、优先级）、评论、附件、状态变更记录、经办人变更记录，以及工时与操作日志。每类对象都要标注数量、时间跨度和所在项目，作为后续批次划分和核验的基数。
历史记录无法与 Jira 完全等价，因此盘点阶段就要给每类记录定保留等级。建议分三档：必须保留、可摘要保留、可丢弃。判断依据是这条记录是否影响业务追溯或审计，而不是它在 Jira 里是否存在。
| 记录类型 | 建议保留等级 | 判断依据 |
|---|---|---|
| 问题标题、描述、类型、优先级 | 必须保留 | 工作项的基本内容，缺失即无法使用 |
| 状态变更记录（含前后值、时间、操作人） | 必须保留 | 反映流转过程，是审计与复盘依据 |
| 经办人变更记录 | 必须保留 | 责任归属追溯需要 |
| 关键评论与附件 | 必须保留 | 承载需求讨论、验收材料 |
| 工时记录 | 视管理需要保留 | 若目标系统继续统计工时则必须迁 |
| 低频操作日志、字段微调记录 | 可摘要保留 | 保留“某时间有人修改”的摘要即可 |
| 系统通知类记录、自动提醒 | 可丢弃 | 不承载业务信息 |
时间区间与项目范围要同时写清。常见做法是只迁近两三年活跃项目，归档项目保留 Jira 只读访问；也有团队要求全量迁移。两种做法都可行，区别在于迁移工作量和核验成本。范围一旦确定，写成清单并由业务方签字确认，后续试迁和验收都以这份清单为准，避免执行中反复扩大范围。
迁移前要准备的四类映射表
映射表是迁移的输入，决定数据落到目标系统后的样子。四类映射表要在正式迁移前完成填写和评审，每张表都保留“来源值—目标值—转换规则—负责人”四列，遇到无法对应的值单独标记，不默认丢弃。
用户映射
把 Jira 账号逐一对应到目标系统账号，匹配优先用邮箱或工号，姓名仅作辅助。离职账号要单独处理：保留其历史记录中的作者显示名，账号本身不新建或归并到接手人，否则变更记录的责任人会失真。重名账号必须用唯一标识区分，不能按姓名批量匹配。映射完成后统计未匹配账号数量，作为迁移前的待办项。
状态与工作流映射
Jira 状态与目标状态往往不是一一对应。先列出 Jira 每个状态及其所属工作流，再标注目标系统中的对应状态；多个 Jira 状态归并到一个目标状态时，写明归并规则，例如“待办、Open、Reopened 统一映射为待处理”。归并会损失状态粒度，需在映射表中注明，并确认业务方接受。状态流转顺序在历史记录中按时间写入，归并后仍要保证先后关系可读。
字段映射
同名字段含义不同是常见问题。例如 Jira 的“优先级”是五级，目标系统是三级，就需要写明转换规则：高、最高归为高，中归为中，低、最低归为低，并在迁移记录中保留原值备查。自定义字段逐个核对类型：文本、单选、多选、日期、数值的转换方式不同，插件生成的字段要确认目标系统是否有承载位置，没有对应位置的字段列入“降级为描述或标签”的处理清单。
附件与富文本
附件映射要确认存储位置、单文件大小上限和文件名编码。评论中的富文本、内嵌图片、@提及需要逐项确认转换方式：内嵌图片通常转为附件并在正文保留引用位置，@提及在用户映射完成后按新账号重写，无法匹配的提及保留原显示名。评论格式的差异要在试迁阶段实际查看渲染效果，而不是只看字段是否写入。
在目标系统一侧，映射结果需要有明确的承载对象。以 ONES 为例，其 Jira 迁移方案的范围覆盖项目、工作项、状态、字段、流程、附件和历史记录，迁移到 ONES Project 时包含用户、用户组、系统配置以及问题的属性、属性值、附件和评论。字段配置、工作流、问题类型这些配置项在迁移前逐项核对，可以减少映射表落地时的返工。
历史记录的执行迁移方法
执行顺序遵循“先主数据、后业务数据、最后历史记录”的原则。主数据包括用户与用户组、项目、问题类型、字段配置、工作流和权限配置；这些就位后，问题才能找到正确的落点。把顺序颠倒，先导问题再补配置，往往需要清空重来。
分批策略按项目或时间切分，两者可以组合。批次划分要考虑三点：单批数据量控制在可核验的范围内，批与批之间有清晰的边界，出问题时能只回退单批。每批开始前记录批次号、来源项目、时间区间、预计问题数与附件数，迁移完成后回填实际数量，形成批次记录表。
- 导出或读取本批来源数据，生成批次清单并冻结，迁移期间来源侧停止修改该批数据。
- 按用户、状态、字段、附件映射表转换数据，转换日志中记录每条规则的命中次数和未匹配项。
- 先写入问题主体，再按时间顺序写入变更历史，每条记录保留作者、时间、变更前后值。
- 写入评论与附件，附件写入后立即校验文件可访问，评论按原时间排序。
- 回填批次记录表，标记本批状态为“已迁移待核验”。
迁移中断后的续跑依赖批次号和唯一标识。每条来源记录在转换时携带来源 ID，写入目标系统后记录目标 ID，形成对照表；续跑时以对照表判断哪些记录已写入，避免重复导入。去重不能只靠标题或创建时间，同名问题在 Jira 中并不少见。批次记录表同时是续跑的依据和核验的底稿，建议与映射表放在同一份迁移文档中管理。
迁移后如何核验数量与内容
核验分两层：数量比对回答“有没有少”，抽样比对回答“内容对不对”。两层都通过，才能进入切换。核验结果要留下可复查的记录，而不是口头确认。
| 核验项 | 方法 | 通过标准 |
|---|---|---|
| 问题数 | 按项目比对来源与目标的工作项总数 | 与批次记录表一致，差异逐条说明 |
| 评论数 | 按项目汇总评论条数比对 | 差异为零或有登记说明 |
| 附件数 | 比对附件数量并抽查文件可打开 | 数量一致，抽查文件内容完整 |
| 变更历史 | 按项目、状态、时间抽取问题，逐条比对状态流转顺序、操作人与时间 | 顺序正确，作者与时间可追溯 |
| 字段值 | 抽取含自定义字段的问题比对转换结果 | 符合映射表规则，原值可查 |
| 评论内容 | 抽查含内嵌图片、@提及的评论 | 格式可读，引用位置正确 |
抽样要覆盖不同维度，而不是随机抽几条了事。建议按项目各抽一批、按状态覆盖首尾状态、按时间覆盖最早和最晚记录，重点抽含附件、含多次状态变更、含离职人员操作的问题。抽样比例按数据量确定，数据量大时至少保证每个项目和每种状态都有样本。
发现差异后登记到差异登记表，字段包括差异类型、涉及记录、来源值、目标值、原因判断和处理结论。处理结论分补迁、接受、降级三类：映射遗漏导致的缺失走补迁，格式差异不影响业务追溯的可接受，无法承载的字段降级为描述或标签。补迁完成后重新核验该批次，并在批次记录表中更新状态。
回退与停止条件
停止条件在迁移开始前约定，触发时暂停当前批次而不是继续推进。可量化的阈值比“感觉不对”更有效，例如：单批问题数量差异超过约定比例、关键字段（状态、经办人、优先级）映射错误影响超过若干条、附件缺失或无法打开、变更历史的作者或时间出现系统性错位。阈值由业务方和技术负责人共同确认，写进迁移方案。
回退点按批次设置。每批迁移前保留来源侧快照或导出备份，目标系统侧记录本批写入的范围，确保可以只清除单批数据而不影响已验收批次。回退操作包括：暂停后续批次、清除本批写入记录、核对来源数据未被修改、修正映射规则后重新试迁。回退后重新迁移的前提是映射表已更新并通过小样本验证，不能带着同一个错误规则重跑。
切换前需要业务方确认的验收项包括：范围清单内的对象全部迁移完成、数量核验通过、抽样内容核验通过、差异登记表处理完毕、关键用户能正常查询历史记录。这些确认完成后，才关闭 Jira 的写入权限进入只读阶段。ONES 的迁移建议也提到，把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配，这与按批次设置回退点的做法一致。历史记录的保真粒度、分批续跑机制和核验报告形式，需要在实施前与迁移服务方逐项确认，再据此调整本文的核验清单。
常见问题
Jira 历史记录迁移中，哪些记录可以只保留摘要？
判断标准是这条记录是否影响业务追溯或审计。状态变更、经办人变更、关键评论与附件通常需要完整保留；低频操作日志、字段微调记录可以只保留“某时间有人修改”的摘要；系统通知和自动提醒类记录不承载业务信息，可以丢弃。工时记录视目标系统是否继续统计工时决定。摘要保留会损失细节，需在范围清单中注明并取得业务方确认。
Jira 状态与目标系统状态不是一一对应时，历史记录里的流转顺序还能读出来吗？
可以，前提是归并规则写清楚并按时间顺序写入。多个 Jira 状态归并到一个目标状态时，在映射表中注明归并关系，历史记录仍按原时间顺序写入，保留操作人与变更前后值。归并会损失状态粒度，例如“待办、Open、Reopened”统一为“待处理”后，无法从目标状态直接区分来源状态，需要时可在记录中保留原值备查。试迁阶段应实际查看几条多次流转的问题，确认顺序可读。
迁移中断后重新执行，怎样避免重复导入？
依赖来源 ID 与目标 ID 的对照表。每条来源记录转换时携带来源 ID，写入目标系统后记录目标 ID；续跑时先查对照表，已写入的记录跳过，未写入的继续处理。去重不能只靠标题或创建时间，同名问题在 Jira 中并不少见。批次记录表同时记录批次号、来源项目、时间区间和预计与实际数量，中断后按批次恢复，避免整批重跑。
抽样核验抽多少条才够？
抽样比例按数据量确定，重点是覆盖维度而不是追求随机。建议每个项目都抽一批，状态覆盖首尾两端，时间覆盖最早和最晚记录，并重点抽取含附件、含多次状态变更、含离职人员操作的问题。数据量大时至少保证每个项目和每种状态都有样本。抽样发现系统性错误时，应扩大样本或暂停该批次，而不是继续按原比例抽完。
什么情况下应该停止迁移并回退？
停止条件在迁移前约定为可量化阈值，例如单批问题数量差异超过约定比例、关键字段映射错误影响超过若干条、附件缺失或无法打开、变更历史的作者或时间出现系统性错位。触发后暂停当前批次，清除本批写入记录，核对来源数据未被修改，修正映射规则并重新小样本验证后再迁。回退点按批次设置，每批迁移前保留来源侧快照或导出备份，确保只清除单批而不影响已验收批次。
ONES 的 Jira 迁移方案覆盖哪些内容，历史记录保真到什么程度？
根据 ONES 公开的方案说明，其 Jira 迁移范围覆盖项目、工作项、状态、字段、流程、附件和历史记录；迁移到 ONES Project 时包含用户、用户组、系统配置，以及问题的属性、属性值、附件和评论。方案层面未说明状态变更、经办人变更等操作日志是否逐条保留作者、时间与前后值，也未说明分批续跑与核验报告的具体形式。这些细节需要在实施前与迁移服务方逐项确认，再据此调整核验清单。
