Jira 迁移的关键，是把源端的项目、问题类型、字段和状态按业务含义重新映射到目标系统，再用小范围试迁移验证映射是否成立。本文按范围界定、输入准备、字段与状态映射、试迁移核验、切换与回退五个阶段展开，每一步都给出可交付的清单或表格，帮助负责迁移的团队负责人和管理员判断何时继续、何时暂停。
要点总览（TL;DR）
- Jira 迁移按范围界定、输入准备、字段与状态映射、试迁移核验、切换与回退五个阶段推进，每个阶段都有可评审的清单或表格。
- 字段映射按业务含义而非字段名进行：同名字段先比对取值枚举与业务定义，再决定直接映射、值转换、拆分或归档不迁。
- 试迁移选取覆盖主要问题类型与字段的代表性项目，核验记录数量、必填字段值、状态分布、附件与评论完整性，并抽样逐字段比对。
- 切换前设定明确的通过标准，源系统保留只读窗口；出现记录缺失、字段错位或附件评论成批丢失时暂停并回退。
- 目标系统为 ONES 时，其 Jira 数据迁移覆盖项目、系统配置、问题数据与用户用户组，具体字段类型与状态历史的覆盖范围需在试迁移中逐项确认。
迁移范围：从 Jira 的哪些项目和对象开始
迁移方向必须先写清楚：源系统是 Jira，目标系统是团队实际选定的平台，数据从 Jira 流向目标系统。方向一旦颠倒，后续的导出、映射和核验都会失去基准。范围界定阶段的任务，是把“要迁什么”变成一份可以逐项打勾的清单，而不是一句“把 Jira 迁过去”。
圈定范围通常从三个维度收口。项目维度列出本次迁移的 Jira 项目键，区分全量迁移、只迁活跃项目、只迁归档项目；问题类型维度列出缺陷、任务、需求、子任务等需要保留的类型；时间区间维度明确历史数据的截止点，例如只迁最近三年的问题，更早的数据以只读归档方式保留。三个维度交叉后，范围清单才具备可执行性。
对象类别需要逐项列明。常见迁移对象包括：问题及其属性值、评论、附件、状态历史与流转记录、用户与用户组、项目权限配置。每类对象都要标注“迁移”“归档不迁”“暂不处理”三种处置方式之一，避免执行阶段临时决定。
同时要明确写出不在本次范围内的对象。Jira 插件产生的数据、自动化规则、看板与过滤器配置、仪表盘、Jira Service Management 的工单门户配置，通常需要单独评估，不能默认随问题数据一起迁移。插件相关的定制场景在迁移前应逐项评估，确认目标系统是否有对应能力承接，再决定替代方案。
| 范围维度 | 需要填写的内容 | 处置方式 |
|---|---|---|
| 项目 | 项目键、项目名称、活跃/归档状态 | 迁移 / 归档不迁 |
| 问题类型 | 缺陷、任务、需求、子任务等 | 迁移 / 合并到目标类型 |
| 时间区间 | 历史数据截止日期 | 迁移 / 只读保留 |
| 对象类别 | 问题、评论、附件、状态历史、用户与权限 | 迁移 / 暂不处理 |
| 排除项 | 插件数据、自动化规则、看板与过滤器 | 单独评估 |
这份范围清单的完成标志是：每个项目、每种问题类型、每类对象都有明确处置方式，排除项有书面说明，并且经过业务方确认。
本阶段输入与依赖：迁移前要准备哪些数据
范围确定后，迁移能否顺利推进取决于输入材料是否齐备。这一阶段的产出是一份迁移输入清单和责任人对照表，把“谁提供什么、什么时候提供”固定下来。
源端输入包括 Jira 的导出数据与字段清单。导出方式按实际环境确定，常见做法是通过 Jira 自带导出、备份或迁移工具获取项目数据，导出前要确认导出范围与范围清单一致，并记录导出时间点作为数据快照。字段清单要覆盖系统字段和自定义字段，标注每个字段的类型、取值枚举和使用该字段的问题类型，这是后续映射的基础材料。
目标端输入包括项目结构、问题类型方案、工作流配置和字段配置。目标系统的项目与问题类型需要在迁移前建好，工作流状态和流转规则要与业务方确认，字段配置要明确哪些字段必填、哪些字段有枚举约束。目标端配置越早稳定，映射表返工越少。
用户与权限的对应关系是容易被低估的依赖。需要准备 Jira 用户与用户组的清单，以及目标系统账号的对应规则：哪些用户按邮箱匹配、哪些需要新建、哪些离职账号只保留历史记录不迁活跃权限。权限配置的映射要落到项目角色和操作权限两个层面，不能只迁用户不迁权限。
最后要指定字段含义的确认人。每个业务域（如需求管理、缺陷管理、测试管理）应有明确的业务负责人，对“这个字段在业务上代表什么”给出结论。技术团队负责迁移执行，业务确认人负责含义判断，两者职责分开，映射争议才有裁决依据。
| 输入项 | 内容 | 责任人 | 完成标志 |
|---|---|---|---|
| 源端导出数据 | 项目数据、字段清单、附件包 | Jira 管理员 | 导出完成并记录时间点 |
| 目标端配置 | 项目、问题类型、工作流、字段配置 | 目标系统管理员 | 配置评审通过 |
| 用户与权限 | 用户清单、用户组、项目角色 | IT 或 HR 对接人 | 账号对应表确认 |
| 字段含义确认 | 各业务域字段定义 | 业务负责人 | 字段定义签字确认 |
字段映射方法：同名字段含义不同怎么处理
字段映射的核心原则是按业务含义映射，而不是按字段名照搬。两个系统里都叫“优先级”的字段，取值可能是“最高/高/中/低/最低”对“P0/P1/P2/P3”，也可能一个用于排期、一个用于严重程度。直接同名映射会把业务语义带错，后续报表和筛选都会失真。
建议先建立一张字段映射表，至少包含五列：源字段、源含义、目标字段、目标含义、转换规则。转换规则要写清楚是直接映射、值转换、拆分到多个字段，还是合并、归档不迁。同名字段先比对取值枚举和业务定义，再决定映射方式；枚举不一致时给出值对照表，例如把五级优先级压缩为三级时，明确哪些值合并到哪一级。
| 源字段 | 源含义 | 目标字段 | 目标含义 | 转换规则 |
|---|---|---|---|---|
| 优先级 | 排期紧急程度，五级 | 优先级 | 处理顺序，三级 | 值转换：最高/高→高，中→中，低/最低→低 |
| 问题类型 | 缺陷、任务、需求、子任务 | 工作项类型 | 缺陷、任务、需求、子任务 | 直接映射，子任务挂接父项 |
| 自定义字段“客户” | 提出需求的客户名称 | 自定义字段“客户” | 客户名称 | 直接映射，空值保留为空 |
| 自定义字段“环境” | 缺陷复现环境，低频使用 | 不迁移 | — | 归档到只读快照 |
自定义字段要按使用频率和业务价值分级。高频且参与报表、筛选、流转条件的字段优先迁移；低频、历史遗留、仅少数项目使用的字段可以归档不迁，在只读快照中保留原值。分级结论要写进映射表，避免执行时逐字段临时讨论。
状态与工作流的映射单独成表。源端的每个状态要对应到目标状态，流转历史按时间顺序保留为历史记录。状态名称相同但流转规则不同的情况很常见，例如 Jira 的“进行中”可能包含开发中和测试中两个子状态，目标系统只有一个“进行中”，这时要么在目标端拆分状态，要么在映射表中注明合并规则并接受历史粒度损失。
附件、评论和关联关系的映射规则同样要落到表里。附件按问题挂接，文件名冲突时给出重命名规则；评论保留作者和时间，作者账号无法对应时标注为历史用户；问题之间的关联（阻塞、关联、重复）映射为目标系统的对应关系类型，无法对应的关联类型列入例外说明。
如果目标系统是 ONES，其 Jira 数据迁移能力覆盖项目、系统配置（含问题类型、工作流、字段配置、权限配置）、问题数据（含属性和属性值、附件、评论）以及用户和用户组。映射表仍要逐项确认具体配置项的覆盖范围，尤其是自定义字段类型和状态历史的保留程度，需要在试迁移中验证，不能仅凭能力清单假设全部等价。
试迁移与核验：用小范围验证映射是否正确
映射表完成后不要直接全量迁移。先选一到两个代表性项目做试迁移，项目要覆盖主要问题类型和主要字段，最好包含一个有较多自定义字段、一个有较长状态历史、一个有大量附件的项目，这样一次试迁移能暴露多数映射问题。
核验按固定项逐条执行，每项都要留下证据：
- 记录数量：源端与目标端的问题总数、各问题类型数量是否一致，差异要能逐条解释。
- 必填字段值：目标端必填字段是否存在空值，空值是否来自源端本身为空。
- 状态分布：各状态下的问题数量是否与源端对应，合并状态的要按合并规则核对。
- 附件与评论完整性：附件数量、文件大小、评论条数与源端比对，抽查若干条评论的作者和时间。
- 抽样比对：随机抽取若干条问题，逐字段比对源端与目标端的值，覆盖系统字段、自定义字段、关联关系和状态历史。
发现偏差后回到映射表修改规则，再重新试迁移受影响的范围，不要在原数据上手工修补。每次修改都要在映射表中记录版本和修改原因，形成可追溯的修正记录。核验证据建议以截图、导出对照表和核验报告三种形式留存，报告里写明核验项、通过情况、偏差清单和修正结论。
试迁移核验报告的完成标志是：所有核验项有明确结论，偏差项已修正并复验，剩余无法修正的差异有业务方接受的书面说明。
切换与回退：什么条件下继续、暂停或回退
全量切换前要设定通过标准，标准来自试迁移核验结果，而不是主观判断。可用的通过标准包括：记录数量差异为零或全部有解释、必填字段空值率在约定范围内、状态分布与源端一致、附件与评论完整性核验通过、抽样比对无字段错位。任何一项不达标，都应暂停切换而不是带病上线。
切换期间源系统保留只读窗口。窗口长度按团队规模和业务节奏确定，窗口内 Jira 停止写入，用户只能查看，新增工作转入目标系统。窗口的作用是保证源端数据快照稳定，避免切换过程中源端继续产生新数据导致两边不一致。窗口结束前要完成全量迁移和核验，确认无误后再关闭源端写入。
出现以下情况应暂停并回退：关键项目记录数量缺失且无法解释、必填字段大面积空值、状态与工作流错位导致流转无法进行、附件或评论成批丢失。回退动作包括：停止目标系统的用户写入、恢复源系统写入权限、保留已迁移数据作为分析样本、按修正后的映射表重新试迁移。回退不是失败，而是把问题控制在试迁移范围内解决。
| 决策点 | 继续条件 | 暂停/回退条件 |
|---|---|---|
| 试迁移核验 | 核验项全部通过或有书面接受的差异 | 记录数量缺失、字段错位无法解释 |
| 全量切换前 | 通过标准逐项达标 | 任一关键项不达标 |
| 切换窗口内 | 迁移与核验按计划完成 | 附件或评论成批丢失 |
| 切换后 | 用户可正常创建和流转工作项 | 工作流无法流转、权限错配 |
切换完成后要发布用户通知，说明新系统的入口、登录方式、常用操作变化和问题反馈渠道。旧链接的处理要提前规划：Jira 问题链接在目标系统没有对应地址，可在源系统保留只读访问一段时间，或在团队文档中提供新旧编号对照表，减少用户查找成本。整个迁移过程建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配，降低数据丢失或业务中断的风险。
常见问题
Jira 迁移时，自定义字段太多，是否必须全部迁到目标系统？
不必全部迁移。建议按使用频率和业务价值给自定义字段分级：参与报表、筛选或流转条件的高频字段优先迁移；低频、历史遗留、仅少数项目使用的字段可以归档到只读快照，不进入目标系统。分级结论要写进字段映射表，并注明每个字段的处置方式，执行阶段按表操作，避免逐字段临时讨论。
需要留意的是，被判定为低频的字段如果后续业务重新启用，只读快照里的原值仍可查询，但不会出现在目标系统的筛选和报表中，这个取舍要提前与业务方确认。
试迁移要选几个项目、覆盖到什么程度才算够？
数量上通常一到两个代表性项目即可，关键是覆盖度而不是项目数。选取的项目应覆盖主要问题类型和主要字段，最好分别包含：自定义字段较多的项目、状态历史较长的项目、附件量较大的项目。这样一次试迁移能暴露字段映射、状态合并和附件挂接三类典型问题。
如果团队有多个业务域使用差异明显的字段方案，可以按业务域各选一个项目。试迁移范围扩大后，核验工作量同步增加，需要在覆盖度和周期之间做平衡。
迁移切换期间，Jira 还能继续使用吗？
切换窗口内建议将 Jira 设为只读：用户只能查看，新增工作转入目标系统。这样源端数据快照保持稳定，避免切换过程中源端继续产生新数据，导致两边记录不一致。
窗口长度按团队规模和业务节奏确定，窗口结束前要完成全量迁移和核验。窗口内如果发现记录缺失、字段错位或附件评论成批丢失，应暂停切换、恢复源端写入权限，按修正后的映射表重新试迁移，把问题控制在可回退的范围内。
迁移后发现个别问题字段值不对，可以直接在目标系统里手工改吗？
不建议在原数据上手工修补。个别字段错位往往意味着映射规则存在系统性问题，手工改只能修正看到的几条，同类问题还会留在其他记录里。正确做法是回到字段映射表修改转换规则，记录修改原因和版本，再重新试迁移受影响的范围，复验通过后再进入全量切换。
如果偏差确实只涉及极少数记录且原因已定位为源端数据本身异常，可以在核验报告中单独登记，经业务方确认后作为例外处理。
目标系统是 ONES 时，Jira 迁移能覆盖哪些内容，哪些需要提前确认？
根据 ONES 官方资料，其 Jira 数据迁移可迁移项目与系统配置（包括问题类型、工作流、字段配置、权限配置）、问题数据（属性和属性值、附件、评论）以及用户和用户组。涉及插件替代时，ONES 建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配，企业已有的定制场景仍需逐项评估。
具体配置项的覆盖范围，尤其是自定义字段类型和状态历史的保留程度，需要在试迁移中验证，不能仅凭能力清单假设全部等价。迁移方式上，ONES 建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配。
