编写 Jira 迁移方案，核心是把“迁什么、迁到哪、怎么迁、谁负责、怎么验收、出问题怎么退”写成一份团队能照着执行的文档。建议按范围与目标、数据与字段映射、迁移步骤与批次、角色与交付物、校验与验收、回退与切换六块组织，先定范围再排步骤，每个关键动作写清输入、动作、输出和完成标志。下文给出各章的结构、填写规则、示例片段和提交前检查清单。
要点总览（TL;DR）
- Jira 迁移方案按六块组织：范围与目标、数据与字段映射、迁移步骤与批次、角色与交付物、校验与验收、回退与切换，后一块的填写依赖前一块的结论。
- 先定范围再排步骤：项目数量、附件总量和自定义字段复杂度直接决定试迁移样本、批次划分与时间估算，范围未确认就排步骤容易返工。
- 字段映射表用统一列结构承载来源对象、来源字段、目标对象、目标字段、转换规则、责任人和备注，无法映射项登记在附表并指定处理人。
- 每个阶段写清输入、动作、输出和完成标志，试迁移样本覆盖字段常规、工作流复杂和附件量大三类项目，用结果修正映射表。
- 验收标准写成可验证条件并附证据，回退预案写明触发条件、回退步骤、数据保留方式和决策人，提交前按清单逐项核对。
方案先写清哪六块内容
一份可执行的 Jira 迁移方案，读者应当能从中找到六类信息：迁移边界、数据对应关系、执行顺序、人员分工、验收方法、风险处置。这六块内容构成方案的骨架，章节顺序也建议按此排列，因为后一块的填写依赖前一块的结论。
| 章节 | 回答的问题 | 完成标志 |
|---|---|---|
| 范围与目标 | 迁哪些项目、哪些对象，什么算迁移成功 | 保留清单与不迁移清单经业务方确认，成功标准可逐条验证 |
| 数据与字段映射 | 来源字段对应目标哪个字段，怎么转换 | 映射表覆盖全部在用字段，无法映射项有记录和处理人 |
| 迁移步骤与批次 | 分几个阶段、按什么顺序、分几批执行 | 每阶段有输入、动作、输出和完成标志，批次清单确定 |
| 角色与交付物 | 谁负责什么，产出什么文档或结果 | 每个角色落实到人，交付物有提交时间 |
| 校验与验收 | 怎么核对数据，达到什么条件算通过 | 校验清单可逐项执行，验收标准有证据要求 |
| 回退与切换 | 什么情况回退，怎么回退，切换后观察多久 | 回退触发条件、步骤和决策人明确 |
先定范围再定步骤，原因在于范围直接决定迁移对象和数据量：项目数量、附件总量、自定义字段复杂度都会影响试迁移样本的选择、批次划分和时间估算。范围未定就排步骤，后续调整会牵动映射表、人员安排和验收标准，返工成本高。因此方案编写时，前两章应先形成初稿并经业务方确认，再进入步骤编排。
范围与目标怎么写才可执行
范围章节的任务是划出清晰边界，让所有人对“迁什么”有同一份清单。写法上建议按对象类型逐项列出取舍，而不是笼统写“迁移全部研发数据”。
需要逐类确认的对象包括：项目、问题类型、状态与工作流、自定义字段、附件、评论、历史变更记录、用户与用户组、权限方案、看板与过滤器、插件产生的数据。每一类给出三种结论之一：迁移、暂不迁移、迁移但降级处理（例如历史变更记录只保留关键节点）。
成功标准要写成可验证条件，避免“数据完整迁移”这类无法判定的表述。可用的写法如：全部在册项目的工作项数量与来源系统一致；附件可正常下载打开；关键字段抽样一致率达到约定值；用户登录后能看到与原系统一致的项目权限。每条标准后面注明验证方式和责任人。
迁移窗口与停机假设也要写进本章：计划在什么时间段执行正式迁移，期间原系统是否停止写入，业务方需要提前多久冻结变更。停机假设影响后续批次编排，例如无法长时间停机时，需要设计增量同步或分批切换的方式。这一部分的具体时间需结合团队实际排期确定，方案中写明假设条件即可。
数据与字段映射表怎么设计
字段映射表是方案中工作量最大、也最影响迁移质量的部分。建议用一张主表承载全部对应关系，列结构如下：
| 来源对象 | 来源字段 | 目标对象 | 目标字段 | 转换规则 | 责任人 | 备注 |
|---|---|---|---|---|---|---|
| 问题 | 状态 | 工作项 | 状态 | 按状态对照表逐项对应，无对应状态归入“待处理” | 数据负责人 | 需业务方确认对照表 |
| 问题 | 自定义字段（如“需求来源”） | 工作项 | 自定义属性 | 选项值按清单映射，多余选项合并或新增 | 数据负责人 | 选项值清单附后 |
状态与工作流的对应建议单独做一张对照表：列出原系统每个状态、目标系统的对应状态、转换动作是否保留。工作流中的条件、校验和触发器如果目标系统无法一一对应，要在备注中写明替代做法或简化方案，并标注由谁确认。
自定义字段的处理分三步：先盘点全部在用字段及其选项值，再判断目标系统是否有同类字段，最后确定转换规则。选项值多于目标系统允许范围时，写明合并规则；字段类型不同（如多选变单选）时，写明取值优先级。字段数量多时，可按使用频率排序，低频字段单独标注处理方式。
用户与权限的对应需要两张清单：用户清单（账号、姓名、所属组）和权限清单（项目角色、权限方案、可见范围）。迁移后权限应与原系统预期一致，差异项要逐条记录并说明原因。无法映射的字段、状态或权限，统一登记在“待处理项”附表中，写明影响范围、处理人和处理时限，避免在正文中散落。
迁移步骤与批次如何编排
迁移步骤建议划分为四个阶段：准备、试迁移、正式迁移、切换后观察。每个阶段在方案中用表格写清输入、动作、输出和完成标志，判断阶段是否真正结束。
| 阶段 | 输入 | 主要动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 准备 | 范围清单、映射表初稿 | 盘点数据量、确认目标环境、准备账号与权限、冻结变更通知 | 环境就绪记录、冻结通知 | 目标环境可登录，业务方确认冻结时间 |
| 试迁移 | 样本项目、映射表 | 迁移样本数据、核对结果、修正映射表 | 试迁移报告、映射表修订版 | 样本校验通过，映射表问题项关闭 |
| 正式迁移 | 全量数据、修订版映射表 | 按批次执行迁移、逐批核对 | 批次迁移记录、差异清单 | 全部批次完成，差异清单有处理结论 |
| 切换后观察 | 迁移完成记录 | 业务方试用、问题收集、必要修补 | 观察期问题台账、关闭记录 | 观察期结束，遗留问题有明确安排 |
分批策略通常有两种：按项目分批，适合项目之间数据独立、团队使用节奏不同的情况；按团队分批，适合多个团队共用工作流和字段配置的情况。选择哪种，取决于范围章节中确认的项目结构和权限方案。批次之间留出核对时间，前一批的问题修正后再启动下一批。
试迁移样本要覆盖典型场景：选一个字段配置常规的项目、一个工作流复杂或自定义字段较多的项目，再选一个附件量大的项目。样本不必多，但要能暴露映射表的主要问题。试迁移结果用于修正映射表和时间估算，修正记录附在方案后。
角色分工与交付物怎么定
角色章节要解决“谁在什么时间交出什么”的问题。建议用对照表把角色、职责和交付物绑定，每个角色写到具体人名或岗位。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 迁移负责人 | 统筹方案、协调资源、决策批次调整 | 迁移方案、批次计划、问题决策记录 |
| 业务方代表 | 确认范围、状态对照表和验收标准 | 范围确认单、验收签字 |
| 数据负责人 | 维护映射表、执行数据核对 | 字段映射表、试迁移报告、差异清单 |
| 验证人 | 按校验清单逐项核对并记录证据 | 校验记录、验收证据包 |
| IT/运维 | 准备环境、账号权限、执行迁移操作 | 环境就绪记录、迁移执行日志 |
评审与签字节点建议设三个：范围与映射表定稿后评审一次，确认迁移边界和数据对应关系；试迁移报告出来后评审一次，确认问题修正情况和正式迁移时间；正式迁移完成、验收通过后签字关闭。每个节点写明参与人和评审结论的记录方式，避免口头确认。
迁移完成后的日常工作项、文档和评审状态需要有承载位置。ONES 支持围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，也支持迁移用户、用户组、问题类型、工作流、字段配置、权限配置以及问题属性、附件和评论等信息，迁移后的工作项与文档可在同一平台继续管理，便于把验收记录和后续协作放在一起。具体可迁移范围需在迁移前按实际使用情况逐项确认。
校验、验收与回退怎么写
校验章节给出迁移后逐项核对的方法，建议按对象类型列清单：记录数核对（各项目工作项数量与来源系统比对）、附件核对（数量一致且可打开）、字段值核对（关键字段抽样比对）、权限核对（用户登录后可见范围与预期一致）、评论与历史记录核对（抽查关键工作项的评论完整性和变更记录）。每项写明核对人、抽样比例和记录方式。
验收通过标准要与范围章节的成功标准对应，并附证据要求：校验记录表、差异清单及处理结论、业务方试用反馈。验收结论由业务方代表签字确认，证据归档到统一位置。
回退预案写四件事：触发条件（如关键数据缺失率超过约定阈值、核心流程无法运行）、回退步骤（停止写入、恢复原系统访问、保留迁移数据用于分析）、数据保留方式（迁移期间产生的数据如何处置）、决策人（谁有权宣布回退）。切换后观察期建议明确时长和问题收集渠道，观察期内发现的问题按严重程度分级处理，观察期结束形成关闭记录。
一个迁移方案片段示例
以下为演示情景，用于说明前述结构如何落地，实际填写需替换为团队真实数据。
范围与目标片段：本次迁移覆盖研发一部在用的 3 个项目，迁移工作项、附件、评论、用户与项目权限；历史变更记录仅保留状态变更节点；两个已归档项目暂不迁移，保留只读访问至年底。成功标准：3 个项目工作项数量与来源系统一致；附件抽样 50 个全部可打开；关键字段抽样一致；项目成员登录后可见范围与预期一致。
字段映射片段：
| 来源对象 | 来源字段 | 目标对象 | 目标字段 | 转换规则 | 责任人 | 备注 |
|---|---|---|---|---|---|---|
| 问题 | 状态“待验证” | 工作项 | 状态“待验收” | 按对照表直接对应 | 数据负责人 | 业务方已确认 |
| 问题 | 自定义字段“优先级说明” | 工作项 | 无对应字段 | 合并写入描述末尾 | 数据负责人 | 待处理项，附处理时限 |
阶段步骤片段：试迁移阶段，输入为样本项目 A（字段常规）和项目 B（工作流复杂），动作为执行迁移并逐项核对，输出为试迁移报告，完成标志为样本校验通过且映射表问题项全部关闭。正式迁移按项目分三批，每批完成后核对记录数并留一天修正时间。
验收条目片段：项目 A 工作项数量与来源系统一致，差异为 0；附件抽样 50 个可打开率 100%；项目成员权限核对无差异；业务方试用一周无阻断问题。证据为校验记录表和业务方签字确认单。
提交前的完成检查
方案定稿前，按以下清单逐项核对，任一项不满足即视为未达到可执行状态。
- 范围清单覆盖全部对象类型，保留与不迁移项均有业务方确认记录。
- 成功标准每条都有验证方式和责任人，没有无法判定的表述。
- 字段映射表覆盖全部在用字段，状态对照表、用户与权限清单齐全，无法映射项登记在附表并有处理人。
- 每个阶段都写清输入、动作、输出和完成标志，批次划分与范围和数据量匹配。
- 角色对照表落实到人，交付物有提交时间，三个评审节点明确。
- 校验清单可逐项执行，验收标准有证据要求，回退触发条件、步骤和决策人明确。
- 迁移窗口、停机假设和观察期安排与业务方排期一致。
阻断项通常集中在三处：范围未确认导致映射表反复修改、无法映射项没有处理结论、回退预案缺少决策人。补齐这三项后，方案即可提交评审。涉及具体版本兼容、迁移周期和批次上限的信息，需在方案定稿前向服务方确认后填入，不在方案中留空或估算。
常见问题
迁移方案写到什么程度算可以提交评审？
判断标准是团队能否照着方案直接执行，而不是篇幅长短。提交前至少满足：范围清单覆盖全部对象类型并有业务方确认记录；成功标准每条都有验证方式和责任人；字段映射表覆盖在用字段，无法映射项有处理人和时限；每个阶段有输入、动作、输出和完成标志；角色落实到人，交付物有提交时间；校验清单可逐项执行，回退预案有决策人。
常见阻断项集中在三处：范围未确认导致映射表反复修改、无法映射项没有处理结论、回退预案缺少决策人。这三项补齐后即可提交评审。
原系统里有大量自定义字段和插件产生的数据，方案里怎么处理？
先把全部在用自定义字段和插件数据盘点出来，按使用频率排序，再逐项判断目标系统是否有同类字段。有同类字段的写转换规则；类型不同的写取值优先级；没有对应位置的，登记为待处理项，写明影响范围、处理人和处理时限，并说明是合并写入描述、降级保留还是暂不迁移。
插件产生的数据需要单独评估，因为其结构往往与标准字段差异较大。方案中给出评估结论和处理方式即可，具体转换规则可在试迁移阶段验证后补充。
无法长时间停机，迁移批次怎么安排？
停机假设是范围章节必须写明的条件，它直接决定批次策略。无法长时间停机时，常见做法是缩小单批数据量、增加批次数量，并在批次之间留出核对时间；也可以先迁移历史数据，再在短窗口内完成增量部分和切换。
无论采用哪种方式，方案中要写清每个批次的起止时间、冻结写入的范围和时长、核对由谁执行。批次划分与范围章节确认的项目结构和权限方案匹配，前一批的问题修正后再启动下一批。
迁移后验收由谁签字，需要保留哪些证据？
验收结论建议由业务方代表签字确认，验证人负责提供核对记录。证据通常包括：校验记录表（记录数、附件、字段值、权限的核对结果）、差异清单及处理结论、业务方试用反馈、观察期问题台账及关闭记录。
证据归档到统一位置，并与范围章节的成功标准逐条对应，便于评审时核对每条标准是否都有对应证据。口头确认不作为验收依据。
迁移完成后，工作项、文档和评审记录放在哪里继续管理？
迁移方案收尾时，应明确迁移后数据的日常承载位置，避免验收记录和后续协作分散在多个工具中。ONES 支持围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，也支持迁移用户、用户组、问题类型、工作流、字段配置、权限配置以及问题属性、附件和评论等信息，迁移后的工作项与文档可在同一平台继续管理。
具体可迁移范围需在迁移前按实际使用情况逐项确认，涉及版本兼容和迁移周期的信息向服务方确认后填入方案。
