Jira 迁移可以按“定范围—盘对象—做映射—试迁移—校验—切换与回退”六步推进。先锁定要迁的项目、问题类型、字段、附件和用户，再处理同名字段含义不同、状态与工作流不对等、历史记录与附件归属等难点，用少量代表性项目试迁移验证映射，核验通过后分批切换并保留可回退窗口。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，可承接迁移后的字段、状态与核验管理。
要点总览（TL;DR）
- Jira 迁移按“定范围—盘对象—做映射—试迁移—校验—切换与回退”六步推进，各步骤可迭代，不必严格串行。
- 迁移前先按活跃度、归档价值和合规留存要求划分批次，盘点项目、问题、字段、附件、评论、用户权限与工作流，并明确哪些数据只读保留、哪些不迁。
- 字段映射以字段字典为基础，同名不同义按业务含义重新命名或拆分，枚举值用值域对照表处理，无法对应时设兜底值并在备注保留原值。
- 试迁移选取含自定义字段、多状态流转、附件与评论的代表性项目，重点观察字段丢失、状态错位、附件归属和用户匹配失败。
- 核验采用数量对照、分层抽样与关键流程走通三类证据，通过后分批切换，并提前写清回退触发条件和数据处置方式。
迁移范围怎么定：哪些项目、对象和用户要迁
迁移范围决定后续工作量与风险边界。建议先按“活跃项目、低频归档项目、合规留存项目”三类划分批次：活跃项目优先迁，低频项目可延后或只读保留，涉及审计、合同或监管留存的数据先确认留存期限和访问方式，再决定是否迁移。一次性全量迁移会把字段冲突、权限差异和历史数据问题集中放大，分批推进更容易定位问题。
范围清单至少覆盖以下对象：
- 项目：项目键、名称、负责人、成员、项目类别。
- 问题：问题类型、状态、优先级、经办人、报告人、创建与更新时间。
- 字段：系统字段、自定义字段、字段配置方案与必填规则。
- 附件与评论：附件数量、大小、评论作者与时间。
- 用户与权限：账号、用户组、项目角色、问题安全级别。
- 工作流：状态、流转条件、后处理动作与触发器。
同时明确“不迁”的部分。例如已归档且仅用于查询的历史项目，可以保留在原系统只读访问；测试项目、重复创建的临时项目可以清理后不迁；个人看板、临时过滤器等非核心配置可以按需重建。范围清单需要项目负责人和工具管理员共同确认，确认后的版本作为后续映射和核验的基准。
迁移前要准备哪些输入和依赖
迁移启动前需要把输入、权限和责任人对齐，否则试迁移阶段容易反复。Jira 侧先确认导出权限：执行迁移的账号需要具备项目浏览、问题查看、附件下载和必要的管理权限；导出方式按数据量和目标系统支持情况选择，常见做法包括使用迁移工具直连、导出数据包再导入，或通过 API 分批拉取。具体采用哪种方式，需要结合 Jira 版本、部署形态和目标系统的导入能力确认。
目标系统侧要提前准备项目结构、字段体系和用户体系。项目结构包括项目数量、项目键命名规则和项目模板；字段体系包括需要保留的自定义字段、字段类型和必填规则；用户体系包括账号创建方式、用户组划分和项目角色分配。用户映射表要记录 Jira 账号与目标账号的对应关系，遇到离职账号、共享账号或外部协作账号时单独标注处理方式。
建议准备三份基础文档，并明确责任人与确认方式：
| 文档 | 内容 | 责任人 | 确认方式 |
|---|---|---|---|
| 字段字典 | 字段名、类型、取值范围、业务含义、是否必填 | 工具管理员 | 业务负责人逐项确认 |
| 状态字典 | 原状态名、含义、流转前后关系、对应目标状态 | 研发管理者 | 流程负责人评审 |
| 用户映射表 | Jira 账号、目标账号、用户组、项目角色 | IT 或 HR 接口人 | 账号归属人核对 |
插件与定制场景也要在这一阶段梳理。原来依赖 Jira 插件的功能，先列出实际在用的插件和用途，再逐项评估目标系统能否通过工作项配置、流程自动化或开放能力承接。企业已有的定制字段、脚本和报表，迁移前逐项登记，避免在试迁移时才发现无法对应。
同名字段含义不同时怎么做字段映射
字段映射不能按名称直接对齐。两个系统里都叫“优先级”的字段，取值可能是“最高/高/中/低”和“P0/P1/P2/P3”，业务含义和使用规则也可能不同。正确做法是先建字段字典，把每个字段的名称、类型、取值范围、业务含义、是否必填和所属项目记录下来，再按业务含义决定映射关系。
同名不同义的处理原则是“按含义重新命名或拆分”。例如 Jira 中的“模块”在目标系统中可能对应“组件”或“功能域”，如果含义不完全一致，可以在目标侧新建字段并保留原字段值作为备注；一个字段承载多种业务含义时，拆成两个字段分别映射。枚举值用值域对照表处理，逐项列出原值与目标值的对应关系；无法对应的值设置兜底值，例如“其他”或“未分类”，并在备注字段保留原值，便于后续追溯。
字段映射表可以按以下结构填写：
| 原字段 | 类型 | 原取值示例 | 目标字段 | 目标取值 | 转换规则 | 兜底处理 |
|---|---|---|---|---|---|---|
| 优先级 | 枚举 | 最高、高、中、低 | 优先级 | P0、P1、P2、P3 | 最高→P0，高→P1，中→P2，低→P3 | 空值→P3，备注保留原值 |
| 模块 | 单选 | 订单、支付、风控 | 功能域 | 交易、支付、风控 | 按业务归属重新归类 | 无法归类→其他 |
| 描述 | 富文本 | 含图片与表格 | 描述 | 富文本 | 保留文本与图片，表格转为文本 | 格式丢失处加注说明 |
富文本、附件和关联关系的映射单独处理。富文本中的图片、表格和嵌入内容，需要确认目标系统支持的格式范围，格式无法保留时在正文中加注说明。附件按问题归属迁移，文件名重复时加前缀区分。问题之间的关联关系，例如“阻塞”“关联”“重复”，映射为目标系统支持的关联类型；无法对应的关联类型，在评论或备注中记录原关系。
试迁移怎么做：小批量验证映射与流程
试迁移的目标是用少量数据暴露映射问题，而不是验证全量迁移速度。样本选择要有代表性：至少包含一个使用自定义字段较多的项目、一个状态流转较复杂的项目、一个附件和评论量较大的项目。样本项目的问题数量控制在可人工核对的范围内，便于逐条比对。
执行顺序建议按“配置先行、数据随后”推进：先迁移项目结构、问题类型、字段配置和工作流，确认配置在目标系统中可用；再迁移用户和用户组，核对账号匹配结果；最后迁移问题数据、附件和评论。每一步执行后记录开始时间、数据量、异常数量和异常类型，形成试迁移执行记录。
试迁移中重点观察四类异常：
- 字段丢失：自定义字段未出现在目标工作项上，或字段值未写入。
- 状态错位：问题落在错误的状态，或流转历史与目标工作流不匹配。
- 附件归属：附件挂到错误的问题，或文件名、大小异常。
- 用户匹配失败：经办人、报告人或评论作者无法对应到目标账号。
每类异常记录问题编号、影响范围、原因判断和处理方式。试迁移结束后，把问题分为“映射规则需调整”“目标配置需补充”“数据本身需清理”三类，分别回到字段映射表或配置清单中修订，再决定是否进行第二轮试迁移。
迁移后怎么核验：证据、抽样与通过标准
核验要用证据判断迁移是否达标，而不是凭感觉确认。数量核验先做总量对照：问题数、附件数、评论数、用户数分别与源系统统计值比对，差异部分逐项说明原因。数量一致是基础，数量一致不代表内容正确，还需要抽样核验。
抽样按项目、问题类型、字段类型分层进行。每个项目抽取一定比例的问题，覆盖不同问题类型和不同字段类型；重点核对自定义字段值、状态与流转历史、附件和评论作者。抽样比例根据数据量和风险要求确定，高风险项目可以提高比例或全量核对。
业务核验关注关键流程能否在新系统走通：新建问题、流转状态、分配经办人、添加评论和附件、关闭问题，每个动作由实际使用角色操作一遍。权限与可见范围也要核对，确认项目成员能看到应看的数据，非成员无法访问受限项目。
| 核验项 | 核验方法 | 通过标准 |
|---|---|---|
| 问题数量 | 源系统与目标系统总数对照 | 差异在约定范围内且有说明 |
| 字段值 | 分层抽样逐条比对 | 关键字段无丢失，枚举值映射正确 |
| 状态与流转 | 抽查问题流转历史 | 当前状态正确，关键节点可追溯 |
| 附件与评论 | 抽样核对归属与作者 | 附件挂载正确，评论作者匹配 |
| 权限可见性 | 用不同角色账号登录查看 | 可见范围与源系统一致 |
核验记录由执行人填写，项目负责人和工具管理员签字确认。核验未通过的项目不进入切换批次，回到映射或配置环节修正后重新核验。
切换节奏与回退条件怎么安排
切换按批次推进，每批包含若干项目。切换窗口选择业务低峰期，切换前设置写入冻结：在约定时间内停止在 Jira 中新建和修改问题，完成最后一次增量迁移后再开放目标系统写入。冻结时间根据增量数据量和核验耗时确定，并在切换前通知所有相关成员。
分批切换与并行运行需要取舍。分批切换可以让先迁项目先恢复使用，后迁项目继续在原系统运行；并行运行期两套系统同时可用，适合过渡期需要对照查询的场景，但会增加成员的操作负担和数据不一致风险。建议并行期尽量短，明确每个项目的切换日期和原系统停用日期。
回退触发条件在切换前写清楚，常见条件包括：核验未通过且短时间无法修复、关键流程在目标系统无法走通、数据差异超出约定可接受范围、用户无法登录或权限异常影响正常使用。触发回退后，停止目标系统写入，恢复原系统访问，把切换期间在新系统产生的数据导出留存，待问题修复后重新安排切换。回退决策由项目负责人和工具管理员共同确认，并通过既定渠道通知相关成员。
用 ONES 承接迁移后的研发管理流程
迁移完成后的管理动作需要落到具体配置上。字段字典和状态映射可以直接转化为 ONES 中的工作项类型与属性配置：原 Jira 的问题类型对应工作项类型，字段字典中的字段对应工作项属性，枚举值对照表对应属性选项。ONES 从 Jira 迁移到 ONES Project 时，可迁移项目、系统配置，包括问题类型、工作流、字段配置、权限配置等，也可迁移问题数据，包括属性和属性值、附件、评论等信息，这些能力可以减少迁移后重新搭建配置的工作。
原 Jira 工作流的关键节点，用 ONES 工作项状态与流转承载。迁移前梳理的状态字典和流转关系，在 ONES 中配置为状态和流转规则，保留评审、开发、测试、完成等关键节点，让团队切换后按原有节奏推进工作。用户、用户组和 Jira 系统配置也可迁移到 ONES Project，账号体系准备好后，成员可以较快恢复协作。
迁移核验中发现的问题，建议在 ONES 中建为工作项记录，标注所属项目、问题类型、影响范围和责任人，按状态跟踪到关闭。这样核验问题有统一入口，处理进度可查，回退决策也有据可依。对于原来依赖 Jira 插件的功能，ONES 方案建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配；企业已有的定制场景在迁移前逐项评估，不预设所有插件都能一一对应。
常见问题
Jira 迁移一定要一次性全量切换吗？分批迁移怎么划分批次更稳妥？
不必一次性全量切换。更稳妥的做法是按项目分批推进，先迁活跃项目，低频归档项目延后或保留只读访问，涉及审计、合同或监管留存的数据先确认留存期限和访问方式。
分批的依据可以看三点：项目当前是否仍在产生新问题、历史数据是否只用于查询、项目之间是否存在强关联的跨项目问题链接。强关联项目尽量放在同一批次，避免切换期间跨项目协作中断。每批切换前完成该批项目的核验，未通过的项目不进入本批。
原 Jira 里依赖插件的功能，迁移时怎么处理？
先把实际在用的插件列出来，记录插件名称、用途、使用频率和涉及的项目，再逐项评估目标系统能否通过工作项配置、流程自动化或开放能力承接。
ONES 方案建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配；企业已有的定制场景在迁移前逐项评估，不预设所有插件都能一一对应。评估结论分为“可直接承接”“需调整流程后承接”“暂不迁移”三类，并同步给受影响的团队。
试迁移发现字段值映射错了，是改映射表重跑，还是在目标系统里手工修正？
优先改映射表后重跑。手工修正只适合极少量、已定位清楚的个别数据，因为手工修改不会留下可复用的规则，下一批迁移还会出现同样问题。
处理顺序建议是：先在字段映射表中修订转换规则或兜底处理，再清理试迁移产生的数据，然后重新执行该批试迁移并比对结果。如果问题出在目标侧配置缺失，例如目标字段没有对应选项，则先补配置再重跑。每轮修订都记录在试迁移执行记录中，作为正式迁移的依据。
切换窗口内写入冻结要停多久，冻结期间产生的数据怎么处理？
冻结时长取决于最后一次增量迁移的数据量和核验耗时，没有统一标准。做法是先估算增量数据量，再预留核验和异常处理时间，在切换前把起止时间通知到所有相关成员。
冻结期间停止在 Jira 中新建和修改问题，完成增量迁移后再开放目标系统写入。如果冻结期内确有必须记录的事项，可以约定临时登记方式，切换完成后统一补录到目标系统，并核对补录数量，避免遗漏。
迁移核验通过后，原 Jira 系统要马上停用吗？
建议保留一段只读访问期，再按计划停用。并行运行期两套系统同时可用，适合过渡期对照查询，但会增加成员操作负担和数据不一致风险，因此并行期尽量短，并明确每个项目的切换日期和原系统停用日期。
停用前确认三件事：该批项目核验已签字通过、切换期间在新系统产生的数据已核对、成员已按新流程操作过关键动作。停用后如需追溯历史，可通过迁移后的数据或提前导出的备份查询。
