本文给出一份假设情景下的 Jira 迁移方案示例：某研发团队从 Jira 迁往新平台，方案覆盖目标设定、范围盘点、字段与状态映射、试迁移、验收校验、切换与回退六个环节，并逐项说明填写依据。示例中的团队、数据量和时间均为演示设定，不代表真实客户案例，读者可据此改写为自身团队的方案。
要点总览（TL;DR）
- 示例以约80人、14个在用项目、12万条问题单的演示团队为背景，完整填写了范围盘点、字段与状态映射、角色权限映射、试迁移、切换回退和验收校验六个环节。
- 字段映射遇到一对多时采用合并取值并保留原值，无法映射的字段导出清单备查，迁移目标是业务可继续而非字段数量一致。
- 试迁移按项目类型和历史复杂度分层抽样，切换前设冻结期，回退条件写成可判断的数量阈值和修复时限。
- 五段式结构可直接沿用，项目数量、自定义字段复杂度、集成依赖和合规要求需按团队实际重填。
- 示例中的团队规模、映射规则、验收阈值和切换时间均为演示设定，不构成对任何平台能力、版本兼容或价格的确认。
示例目标：这份迁移方案要解决什么问题
先交代演示情景。假设某研发团队使用 Jira 约五年，团队规模约 80 人，包含 3 条产品线和 1 个平台组，日常在 Jira 中管理需求、任务、缺陷和迭代，累计问题单约 12 万条，附件总量约 200GB，另有若干自定义字段和两套并行工作流。以上数字均为示例假设，用于说明方案如何填写，不对应任何真实客户。
迁移目标要写成可验证的结果，而不是“顺利完成迁移”这类无法检查的表述。示例方案设定四个目标：
- 数据完整率：迁移后问题单数量、评论数量、附件数量与源系统盘点结果一致，差异逐条登记并说明原因。
- 关键流程可用：需求、缺陷、迭代三类主流程在目标平台可完整走通，包括状态流转、必填校验和通知。
- 切换窗口时长：正式切换安排在周末，冻结期从周五 18:00 到周一 09:00，业务中断控制在 1 个工作日内。
- 用户可登录可操作：迁移范围内的活跃用户在切换后首个工作日能登录并处理各自待办。
方案覆盖范围同样要写清楚。示例中，3 条产品线的在用项目全部迁移，已关闭超过两年的归档项目只迁移问题单和关键字段，附件按需保留；Jira 中的系统配置、问题类型、工作流、字段配置和权限配置纳入迁移评估；插件依赖单独梳理，不默认全部可对应。方案不覆盖 Jira 之外系统的数据，也不涉及目标平台的版本选型和商务条件。需要强调，这是一份演示方案，用于展示填写结构和决策方式，不能当作真实项目的实施记录。
完整示例：一份填好的 Jira 迁移方案
下面按方案的实际章节给出填写结果，读者可以直接对照自己的项目替换内容。
迁移范围清单
| 对象 | 处理口径 | 示例说明 |
|---|---|---|
| 在用项目 | 全量迁移 | 3 条产品线共 14 个项目，含问题单、评论、附件、历史记录 |
| 归档项目 | 部分迁移 | 仅迁移问题单与关键字段，附件按清单保留 |
| 问题类型 | 映射后迁移 | 需求、任务、子任务、缺陷、改进建议 |
| 附件 | 全量迁移 | 约 200GB，迁移前做完整性抽样 |
| 评论与历史记录 | 全量迁移 | 保留作者与时间，用于追溯决策过程 |
| 插件数据 | 逐项评估 | 先梳理实际使用的插件，再判断替代方式 |
字段与状态映射表
| Jira 对象 | 目标平台对应 | 转换规则 |
|---|---|---|
| 问题类型“缺陷” | 工作项类型“缺陷” | 一对一，保留原有编号规则 |
| 优先级（5 级） | 优先级（3 级） | 一对多合并：最高/高合并为高，中保留，低/最低合并为低，合并项在备注中保留原值 |
| 自定义字段“模块” | 自定义字段“模块” | 一对一，选项值按名称匹配 |
| 自定义字段“客户编号” | 暂不迁移 | 无对应字段，导出为附件清单备查 |
| 状态“待验证” | 状态“待验收” | 改名对应，流转条件保持一致 |
| 工作流“缺陷流程” | 工作流“缺陷处理” | 节点一一对应，审批节点按目标平台规则重建 |
角色与权限映射
| Jira 角色/用户组 | 目标平台对应 | 说明 |
|---|---|---|
| 项目管理员 | 项目管理员 | 保留配置权限 |
| 开发组 | 开发角色 | 按用户组批量对应 |
| 测试组 | 测试角色 | 保留缺陷创建与流转权限 |
| 只读访客 | 访客角色 | 仅查看，不参与流转 |
试迁移安排
试迁移按项目类型和历史复杂度分层抽样：从 3 条产品线各选 1 个在用项目，再选 1 个归档项目，覆盖简单流程与含审批节点的复杂流程。验证项包括问题单数量核对、附件可下载、评论顺序正确、状态流转可用、权限生效。通过标准设为：抽样项目问题单数量差异为零，附件抽样 50 个全部可打开，主流程各状态可正常流转。试迁移中发现的问题登记为工作项，修复后复测。
切换与回退
正式切换前设置冻结期，冻结期内 Jira 只读，禁止新建和修改。切换窗口为周六 00:00 至周日 22:00，预留周一上午作为缓冲。回退触发条件设定为：迁移后问题单数量差异超过盘点总数的 0.5%，或主流程无法走通且两小时内无法修复。回退步骤为：停止目标平台写入，恢复 Jira 写权限，通知用户回到原系统，保留迁移日志用于复盘。
验收校验清单
| 校验项 | 通过标准 | 责任人 |
|---|---|---|
| 问题单数量 | 与盘点结果一致，差异逐条登记 | 迁移负责人 |
| 附件完整性 | 抽样可打开率 100% | 测试负责人 |
| 主流程可用 | 需求、缺陷、迭代流程走通 | 各产品线负责人 |
| 权限生效 | 各角色按预期可见可操作 | 项目管理员 |
| 用户登录 | 活跃用户切换后首日可登录 | IT 支持 |
逐项解释：每个填写选择背后的依据
先盘点范围再定映射，是因为映射表的每一行都依赖范围清单。如果先设计字段对应关系，再回头发现某些项目不迁移或某些字段实际无人使用，映射工作会返工。示例中先确认 14 个在用项目和归档项目的处理口径，映射表只针对范围内实际使用的字段和状态，工作量可控，也避免为废弃字段设计转换规则。
字段映射遇到一对多时，示例采用“合并取值并保留原值”的原则。优先级从 5 级合并为 3 级，合并后的项在原值备注中留痕，保证历史信息不丢失。遇到无法映射的字段，示例选择暂不迁移并导出清单备查，而不是强行塞进不相关的字段。这个原则的依据是：迁移的目标是保持业务可继续，不是追求字段数量一致；无法对应的项要让人知道它去了哪里。
试迁移按项目类型和历史复杂度分层抽样，是因为不同项目暴露的问题不同。简单项目能验证基础数据搬运，含审批节点的复杂项目能暴露工作流和权限问题，归档项目能验证部分迁移口径。只抽一类项目，容易在正式切换时才发现另一类项目的问题。
冻结期和回退条件的设定依据是业务连续性。冻结期让源系统在迁移期间不再产生新数据，避免边迁边改造成对不上；回退条件写成可判断的阈值和时限，是为了在出现问题时快速决策，避免现场争论。示例把数量差异阈值设为 0.5%，把修复时限设为两小时，这两个数值是演示设定，实际应按团队可接受的风险确定。
验收校验项与迁移目标一一对应：数据完整率对应问题单数量和附件完整性，关键流程可用对应主流程校验，切换窗口对应时间记录，用户可操作对应用户登录检查。验收项不是越多越好，而是要能回答“目标是否达成”。
迁移过程本身也需要被管理。示例中的试迁移问题、映射确认、验收结果都可以作为工作项跟踪，方案文档与盘点清单集中存放，方便责任人在切换前逐项核对。ONES 可用于承接这类迁移任务与文档管理，把范围盘点、映射确认、试迁移缺陷和验收记录放在同一处跟踪状态与责任人；其 Jira 迁移方案也围绕项目、工作项、状态、字段、流程、附件和历史记录展开，并在迁移用户、用户组、系统配置和问题数据时提供对应支持，具体范围需在迁移前逐项确认。
可迁移规律：换一个团队怎么改这份方案
这份方案中可直接沿用的，是五段式结构：范围盘点、映射表、试迁移、验收校验、切换与回退。无论团队大小，这五段都回答了迁移必须回答的问题——迁什么、怎么对应、先试哪里、怎么算成功、出问题怎么办。结构可以照搬，内容必须重填。
需要按团队情况调整的变量主要有四类：
- 项目数量与类型：项目越多，抽样比例和试迁移轮次越要增加；存在多套并行工作流时，映射表要按流程分别列出。
- 自定义字段复杂度：字段越多、选项越复杂，越需要提前确认每个字段是否仍在使用，避免把废弃字段带进新平台。
- 集成依赖：与代码仓库、构建流水线、监控系统有对接的，要单独列出集成清单，确认切换后对接方式。
- 合规要求：涉及数据驻留、审计留痕或特殊审批的，要在方案中增加对应章节，不能套用通用模板。
管理动作上，建议明确三类责任人：映射确认由熟悉 Jira 配置的项目管理员负责，验收由各产品线负责人签字，切换与回退由迁移负责人统一指挥。每次确认留下记录，试迁移发现的问题登记为工作项并跟踪到关闭，交接时有据可查。
把迁移当作一个项目来管，是这套方案能落地的重要原因。迁移任务拆成工作项，设置负责人、截止时间和状态；方案、盘点清单、映射表作为文档与任务关联；切换前的检查项逐条勾选。这样迁移进度和风险在同一个视图里可见，不依赖个人记忆。
适用边界：这份示例在什么情况下不适用
示例假设的团队约 80 人、14 个在用项目、12 万条问题单，属于中等规模、流程相对标准的研发团队。团队规模明显更大、项目数量成倍增加，或存在大量跨项目依赖时，抽样比例、试迁移轮次和切换窗口都需要重新测算，不能直接套用示例中的数值。
涉及强合规、数据驻留或特殊审批流程的组织，需要在方案中补充数据存放位置、访问审计、审批留痕等内容，并提前与合规部门确认。示例未覆盖这些要求，直接套用会遗漏关键环节。
历史数据量很大或插件依赖较多的团队，要额外评估迁移时长、附件存储和插件功能的替代方式。插件功能需要先梳理实际使用情况，再逐项判断替代方案，不能假设所有插件都能一一对应。
最后，示例中的字段映射规则、验收阈值、切换时间均为演示填写，不构成对任何平台能力、版本兼容或价格的确认。实际迁移前，应结合自身盘点结果核验目标平台的字段类型支持、权限模型和迁移工具范围，再定稿方案。
常见问题
团队项目数量比示例多很多，试迁移抽样比例要怎么调整？
示例从3条产品线各选1个在用项目、再选1个归档项目，属于小样本验证。项目数量成倍增加时，建议按项目类型和工作流版本分别抽样，每类至少覆盖1个，并增加一轮全量试迁移。判断标准是：正式切换前，每种工作流和每类自定义字段都至少被验证过一次。
Jira 里的自定义字段类型比较特殊，映射表填不出来怎么办？
先把字段按“仍在使用”和“已废弃”分开，只对在用字段设计映射。遇到目标平台没有对应类型的字段，可以暂不迁移并导出清单备查，或改为附件、文本字段承载关键信息。具体字段类型支持范围需在迁移前向目标平台逐项确认，示例中的映射表不能替代这项核验。
冻结期应该设多长，切换窗口不够用怎么办？
冻结期的长度取决于迁移执行时长和业务对停写的容忍度。示例把冻结期设为周五18:00到周一09:00，切换窗口为周六00:00至周日22:00，并预留周一上午缓冲。如果数据量大或试迁移发现问题较多，可以延长窗口或拆成多次分批切换，把影响面控制在单个产品线内。
迁移过程中的任务和文档用什么方式跟踪比较稳妥？
把范围盘点、映射确认、试迁移缺陷和验收记录拆成工作项，设置负责人、截止时间和状态，方案文档与任务关联，切换前逐项核对。ONES 可用于承接这类迁移任务与文档管理，其 Jira 迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录展开，并在迁移用户、用户组、系统配置和问题数据时提供对应支持，具体范围需在迁移前逐项确认。
涉及数据驻留或审计要求时，这份示例要补哪些内容？
需要在方案中增加数据存放位置、访问审计、审批留痕等章节，并提前与合规部门确认。示例未覆盖这些要求，直接套用会遗漏关键环节。若同时存在大量插件依赖，还要先梳理实际使用情况，再逐项判断替代方式，不能假设所有插件都能一一对应。
