Jira 数据迁移的关键，是把源端的项目、问题、字段和状态按业务含义重新映射到目标系统，而不是按名称照搬。本文按盘点、映射、试迁移、核验、切换与回退的顺序展开，说明每一步的输入、产物和判断标准，并以 ONES 作为目标系统示例交代可承接的迁移对象。
要点总览（TL;DR）
- Jira 数据迁移按“冻结范围与版本→盘点对象→建立字段与状态映射→小范围试迁移→数量与抽样核验→分批切换并保留回退点”的顺序推进，每一步都留下可核对的产物。
- 字段映射以业务含义为准：同名字段含义不同时按含义重命名或拆分，无对应字段由业务方逐项确认合并、丢弃、写入描述或保留扩展字段，并记录理由。
- 试迁移样本要覆盖主要问题类型、自定义字段、附件和长评论，按用户与项目结构、问题与字段、评论附件、状态历史的顺序执行，并记录失败项与人工修正项。
- 核验采用数量比对加抽样比对，关键字段建议全量核对；权限越权、关键字段大面积错位、附件批量缺失应触发停止或回退。
- 目标端为 ONES 时，其 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并可迁移用户、用户组及问题类型、工作流、字段配置、权限配置等系统配置，字段级转换规则仍需在试迁移中逐项验证。
迁移范围怎么定：源端、目标端与对象清单
迁移范围决定后续所有工作的边界。范围一旦含糊，映射表会不断加列，试迁移样本也会反复扩大，最终拖长切换周期。建议在动手导出前，先产出一份可核对的迁移范围清单，由业务负责人和目标端管理员共同确认。
清单至少覆盖四个维度：源端环境、目标端结构、迁移对象、保留策略。
| 维度 | 需要写清的内容 | 确认方 |
|---|---|---|
| 源端环境 | Jira 实例形态（云版或数据中心版）、当前版本、站点地址、管理员联系人 | Jira 管理员 |
| 目标端结构 | 目标系统、项目数量与层级、项目负责人、与源端项目的对应关系 | 目标端管理员、业务负责人 |
| 迁移对象 | 项目、问题、评论、附件、用户与用户组、权限配置、工作流状态、历史记录 | 业务负责人 |
| 保留策略 | 哪些历史数据必须完整迁移、哪些只做只读归档、哪些不再保留 | 业务负责人、合规或审计相关方 |
实例形态和版本需要单独确认，因为云版与数据中心版在导出方式、可用字段类型和管理权限上存在差异，这些差异会直接影响导出物能否完整取得。目标端项目结构应在盘点阶段就基本定稿，否则字段映射会失去参照。
历史数据的取舍是范围清单里最容易被跳过的一项。常见做法是把近两三年内仍在被查询、被引用的问题完整迁移，更早的数据以只读方式保留在源端或导出为归档文件。这个划分需要业务方给出判断依据，例如是否涉及审计追溯、是否仍有在办事项引用旧问题。把“全部兼容”当成默认前提，往往在试迁移阶段才发现部分字段无法对应，反而增加返工。
范围清单的完成标志是：每个对象都有数量、保留策略和责任人三列信息，且没有“待定”项。数量可以先取近似值，但必须在试迁移前替换为实际导出数量。
迁移前需要准备哪些输入与依赖
这一阶段的产出是一份输入依赖清单，把“谁提供什么、什么时候提供、缺失时怎么办”写清楚。迁移延期多数不是技术问题，而是某项输入迟迟未确认。
需要提前落实的输入包括：
- 导出权限与管理员配合。确认执行导出所需的账号权限，以及 Jira 管理员在导出窗口期内的可用时间。若使用第三方迁移工具，还需确认该工具访问源端所需的授权方式。
- 字段与状态清单。导出全部问题类型、字段（含自定义字段）、字段配置方案、工作流及其状态和流转规则。这份清单是字段映射表的原始输入。
- 用户名单与附件体量。用户名单需包含账号、邮箱、所属用户组；附件体量需给出总大小和单文件最大值，用于评估传输时间和存储规划。
- 目标端设计定稿。目标系统的项目结构、字段定义、工作流设计应在试迁移前定稿。设计未定稿就做映射，等于在移动的靶子上画线。
- 字段含义确认人。每个关键自定义字段都应有明确的业务确认人，负责回答“这个字段当初为什么建、现在还有谁在用”。
缺失输入的处理方式也要写进清单。例如字段含义确认人暂时无法确定时，可先按字段使用频率排序，优先确认高频字段，低频字段标记为待定并在试迁移中观察影响。导出权限未落实时，不应启动试迁移，因为不完整的导出物会让核验结论失真。
依赖清单的完成标志是：每项输入都有提供方、交付时间和缺失应对方案，且业务方对字段含义确认人名单完成签字或书面确认。
同名字段含义不同时怎么做字段映射
字段映射是整次迁移的核心工作。判断标准是业务含义一致，名称一致只是巧合。Jira 中名为“优先级”的字段，在源端可能承载的是客户等级，在目标端则对应内部处理紧急度，直接按名称对接会把两类信息混在一起。
建议用一张字段映射表承载全部规则，至少包含六列：
| 源字段 | 源含义 | 目标字段 | 目标含义 | 转换规则 | 负责人 |
|---|---|---|---|---|---|
| priority | 客户等级（P1–P4） | 客户等级（自定义单选） | 客户等级 | 值一一对应，保留原选项名 | 客户成功负责人 |
| customfield_10201 | 内部处理紧急度 | 优先级 | 处理紧急度 | 按映射表转换，空值填默认档 | 研发负责人 |
| customfield_10530 | 缺陷发现阶段 | 无对应字段 | — | 写入描述区固定段落 | 测试负责人 |
同名字段含义不同时，处理方式有两种：按业务含义重命名后分别落到不同目标字段，或在目标端拆分字段并保留来源标记。选择哪种取决于两类信息是否需要在同一视图里筛选。若两类信息服务不同角色，拆分更清晰；若只是历史遗留命名冲突，重命名即可。
无对应字段的处置需要在迁移前由业务方逐项确认，常见选项包括合并到相近字段、丢弃、写入问题描述或保留为扩展字段。每种处置都应记录理由，尤其是丢弃，要写明该字段已停止使用或数据可由其他来源还原。
状态与工作流的映射不能只做名称对应。需要同时确认三件事：源状态对应到目标端的哪个状态；目标端工作流的流转限制是否允许历史问题从当前状态继续流转；历史状态变更记录以何种形式保留。若源端存在目标端没有的中间状态，可考虑合并到相邻状态并在历史记录中保留原状态名。
用户与权限映射同样需要一张对照表：账号按邮箱或唯一标识对应，用户组映射到目标端的角色或用户组，权限方案映射到目标项目的权限配置。映射完成后应抽查若干用户，确认其在目标端的可见范围与源端一致。
在目标端为 ONES 的场景下，ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并可迁移用户、用户组以及问题类型、工作流、字段配置、权限配置等系统配置，问题数据中的属性值、附件和评论也在迁移范围内。这些能力为上述映射表提供了落地对象，具体字段级转换规则仍需在试迁移中逐项验证。
试迁移怎么做：样本选择与执行步骤
试迁移的目的是用最小成本暴露映射问题，而不是提前完成正式迁移。样本选得准，一轮试迁移就能发现大部分字段和状态冲突。
样本选择应覆盖：主要问题类型各若干条、使用了自定义字段的问题、带附件的问题、评论数量较多或含长评论的问题、经历过多次状态流转的问题。样本总量不必大，但覆盖面要全，建议每个问题类型至少取五到十条。
执行顺序建议按依赖关系推进：
- 先迁移用户与用户组，再建立目标端项目结构。问题数据需要归属到人和项目，这两步是后续所有数据的前置条件。
- 迁移问题及其字段值。此步重点观察字段映射表的转换规则是否按预期生效。
- 迁移评论与附件。附件需逐条确认可打开，评论需确认作者和时间戳保留。
- 迁移状态历史与流转记录。此步验证工作流映射是否允许问题在目标端继续正常流转。
每批迁移都要留下记录：批次编号、对象类型、计划数量、实际成功数量、失败项清单、人工修正项及修正原因。失败项要分类，区分是映射规则缺失、源数据异常还是目标端配置不支持，三类问题的处理路径不同。
试迁移环境应与正式环境隔离。若在正式环境中试跑，测试数据会混入生产项目，清理成本高于另建环境。隔离方式可以是独立的目标端项目、独立的测试实例，或在正式迁移前清空试迁移数据并重新导入。
迁移结果如何核验：证据与通过标准
核验要回答一个问题：迁移后的数据能否支撑业务继续运转。判断依据是数量比对加抽样比对，两者缺一不可。
数量核验按对象逐项比对源端与目标端的记录数：问题总数、各问题类型数量、评论条数、附件个数、用户数。数量差异要能解释，例如源端存在已删除但仍计入统计的问题，或目标端对某类附件有大小限制。
抽样核验从试迁移样本中抽取记录，逐条检查字段值是否按映射规则转换、状态是否落在预期状态、创建与更新时间戳是否保留、附件能否正常打开、长评论是否完整。抽样比例可根据样本量确定，关键字段建议全量核对。
用户与权限核验通过实际登录抽查完成：选取不同角色和用户组的代表账号，确认其在目标端能看到应看到的问题、看不到不应看到的问题。权限越权属于必须暂停的情形，不能带入正式切换。
证据留存包括核验记录表、差异清单和确认签字。差异清单要写明差异项、影响范围、处理结论（修正、接受或转人工处理）。通过标准建议在试迁移前就约定，例如关键字段零错位、附件可打开率达标、无权限越权，达到标准才进入切换。
切换、回退与停止条件
正式切换按批次推进，每批对应一组项目或一个业务线。批次之间留出观察期，前一批的核验结论作为后一批放行的依据。切换期间需要设置冻结写入窗口，窗口内源端停止新增和修改，避免迁移过程中产生增量数据导致两边不一致。
回退点至少包括两项：源端在切换后保留只读状态的期限，以及触发回退的条件。只读保留期限应覆盖切换后的双轨核对期，具体时长由业务方根据核对工作量确定。回退触发条件可设为关键字段大面积错位、附件批量缺失、权限配置错误导致越权访问等。
停止条件与回退条件不同。停止条件用于在迁移执行中途叫停，防止问题扩大；回退条件用于切换完成后决定是否整体退回源端。停止条件建议明确为：关键字段错位比例超过约定阈值、附件缺失无法在当批修复、出现权限越权。触发停止后，先修复映射或配置，再从上一个成功批次重新执行。
切换后的短期双轨核对是必要的收尾动作。安排专人在约定周期内响应目标端的使用问题，把新发现的数据差异补入差异清单并逐项关闭。ONES 的迁移实践建议把迁移工具、原厂服务和分阶段切换结合使用，并在正式迁移前确认数据范围、功能匹配和系统适配；对于原先依赖 Jira 插件的功能，需要先梳理实际使用的插件再逐项评估对应方式，不能默认所有插件都能一一对应。这些做法与上述批次切换和停止条件的思路一致，具体回退期限和服务范围仍需在项目启动时与相关方书面约定。
常见问题
Jira 云版和数据中心版在迁移准备上有什么差别？
两种实例形态在导出方式、可用字段类型和管理权限上存在差异，这些差异会直接影响导出物能否完整取得。准备阶段应把实例形态、当前版本、站点地址和管理员联系人写进范围清单，并由 Jira 管理员确认导出权限与导出窗口。若使用第三方迁移工具，还需确认该工具访问源端所需的授权方式。具体到某个版本支持哪些导出方式，需要以源端管理员实际确认的结果为准。
历史问题很多，是否必须全部迁移？
不必默认全部迁移。常见做法是把近两三年内仍在被查询、被引用的问题完整迁移，更早的数据以只读方式保留在源端或导出为归档文件。划分依据由业务方给出，例如是否涉及审计追溯、是否仍有在办事项引用旧问题。保留策略要写进范围清单，明确哪些必须完整迁移、哪些只读归档、哪些不再保留，避免试迁移阶段才发现部分字段无法对应而返工。
试迁移发现字段映射错误，应该改映射表还是改目标端字段设计？
先判断问题出在映射规则还是目标端设计。若目标端字段定义本身无法承载源端业务含义，例如两类信息需要分别筛选却只有一个字段，应调整目标端字段设计；若字段定义合理、只是转换规则写错，则修正映射表并重跑受影响批次。目标端设计应在试迁移前定稿，试迁移期间的设计变更要评估对已完成批次的影响，必要时重新执行相关批次。
切换后多久可以关闭源端的只读保留？
只读保留期限应覆盖切换后的双轨核对期，具体时长由业务方根据核对工作量确定，并在项目启动时书面约定。关闭前需要确认差异清单已逐项关闭、没有未处理的权限越权问题、业务方已完成确认。保留期内源端保持只读，一旦触发回退条件可以整体退回；提前关闭会失去这个回退点。
原先依赖 Jira 插件的功能，迁移时怎么处理？
需要先梳理实际使用的插件清单，再逐项评估对应方式，不能默认所有插件都能一一对应。ONES 的迁移实践建议通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配，企业已有的定制场景在迁移前仍需逐项评估。评估结论应写入迁移范围清单，作为停止条件判断的一部分。
