研发数据迁移是把研发管理系统里承载过程和结果的数据，按可追溯、可核对的方式搬到目标系统，并保持对象之间的关联关系。它通常覆盖工作项及其层级、人员与权限、迭代与版本计划、需求与缺陷关联、附件与评论、自定义字段与状态映射等对象，关键环节包括范围盘点、字段映射、关联重建、试迁移核对、正式切换和回退准备。与普通导出或备份相比，迁移的验收标准是目标系统里数据能继续流转，而不只是导出一份文件留存。
要点总览（TL;DR）
- 研发数据迁移是把研发管理系统中的工作项、计划、人员权限、过程记录和配置按映射规则搬到目标系统，并保持对象之间的关联关系，使团队能在新系统中继续工作。
- 迁移对象通常分为五类：工作项及其层级、迭代与版本等计划对象、账号角色与可见范围、评论附件与变更历史、自定义字段与状态选项值，最终清单以盘点结果为准。
- 关键环节包括范围盘点、对象与字段映射、关联关系重建、试迁移与差异核对、正式迁移与切换、回退准备，前一环节的产出是后一环节的依据。
- 迁移与导出、备份的区别在于目标与验收方式：迁移以目标系统内业务可继续使用为验收，导出以文件完整可读为验收，备份以恢复演练结果为验收。
- 字段名相同不代表语义相同，状态和选项值需要建立取值转换规则；迁移也不是一次性动作，切换窗口的增量数据和切换后的观察期核对都需要安排。
研发数据迁移是什么：一句话定义与范围
研发数据迁移指将来源研发管理系统中的项目、工作项、人员权限、计划安排和过程记录，按照事先确定的映射规则搬到目标系统，使团队在新系统中可以继续按原有业务关系开展工作。迁移完成后，一条需求仍能找到它的子任务和关联缺陷，一个迭代仍能包含原来的工作项，评论和附件仍挂在对应对象上。
这个定义包含两个限定。第一，迁移的产出是目标系统中可继续流转的数据，离线文件、Excel 表格或数据库备份只是中间产物。第二，迁移处理的是对象及其关系，单张表的字段值搬运属于数据导入的一部分，完整迁移还需要把对象之间的引用关系重新挂接起来。
判断一次迁移是否成立，可以看三个基本条件：
- 对象齐全：来源系统中在用的项目、工作项、计划、人员、评论、附件等对象，按约定范围完整进入目标系统，没有整类缺失。
- 关系正确：父子层级、需求与缺陷关联、迭代归属、附件与评论的宿主对象等关系在目标系统中指向正确，不出现孤儿数据或错挂。
- 可核对：迁移前后能够按条数、关键字段和抽样明细进行比对，差异有记录、有处理结论。
范围上，本文讨论研发管理数据的整体迁移，包括对象清单和过程环节。工作流定义与插件行为的迁移细节、迁移完成后的验证方法与切换管理流程属于相邻主题，本文只在必要处提及，不展开操作细节。
迁移覆盖哪些数据对象
研发数据迁移的对象清单随来源系统的实际使用情况变化，不同团队对字段、状态和计划对象的用法差异很大，最终清单应以盘点结果为准。按常见研发管理场景，可以把对象分为五类，每类的迁移难点不同。
| 对象类别 | 典型内容 | 迁移难点 |
|---|---|---|
| 工作项类 | 需求、任务、缺陷、子任务及其父子层级 | 层级深度和父子关系需要重建；不同来源系统的类型命名不一致，需要建立类型对应表 |
| 计划类 | 迭代、版本、里程碑及其与工作项的归属关系 | 计划对象与工作项的归属关系需要重新挂接；跨迭代移动过的历史归属需要确认保留口径 |
| 人员与权限类 | 账号、角色、项目成员、可见范围 | 账号需要与目标系统用户体系对应；角色和可见范围的语义差异需要逐项确认 |
| 过程记录类 | 评论、附件、变更历史、状态流转记录 | 记录需要挂到正确的宿主对象上；附件需要保证可下载；历史记录的时间顺序和操作人需要保留 |
| 配置类 | 自定义字段、状态与工作流定义、字段选项值 | 字段名相同不代表语义相同，选项值和状态需要建立取值转换规则 |
工作项类是迁移的主体，数量最大，关系也最复杂。需求、任务、缺陷和子任务之间往往存在多层父子结构和跨类型关联，迁移时需要先确定类型对应关系，再按层级顺序导入，最后校验每条工作项的父级指向。
计划类对象的难点在于归属关系。一个工作项可能经历过多次迭代调整，迁移时要明确保留当前归属还是保留历史归属，这个口径会直接影响迭代视图和统计报表的结果。
人员与权限类对象决定迁移后谁能看到什么。账号对应关系、项目成员名单和角色权限需要与目标系统的权限模型对齐，否则会出现数据已迁入但部分成员无法访问的情况。
过程记录类对象容易被低估。评论、附件和变更历史数量可能远超工作项本身，附件还涉及存储和下载链路，迁移前需要确认容量和文件完整性校验方式。
配置类对象是映射工作的基础。自定义字段的类型、必填规则和选项值，状态与工作流的对应关系，都需要在迁移前形成书面映射表，作为后续核对依据。
关键环节：从盘点到切换的六个步骤
研发数据迁移的过程可以拆成六个环节，每个环节有明确的输入和产出，前一环节的产出是后一环节的依据。环节之间允许迭代，例如试迁移发现映射问题后需要回到映射环节修订规则。
第一步：范围盘点
输入是来源系统的项目列表和使用情况，动作是确认哪些项目、哪些对象类型、哪个时间区间需要迁移，产出是一份范围清单和排除项说明。盘点时要把长期不用的项目、测试数据和重复项目单独标记，避免把无效数据带入目标系统。
第二步：对象与字段映射
输入是范围清单和来源系统的字段、状态、选项值定义，动作是建立来源字段到目标字段的对应关系，并为状态、优先级、选项值等枚举型字段制定取值转换规则，产出是字段映射表和取值转换表。字段名相同但含义不同的情况在这一步处理，例如来源系统的“已解决”与目标系统的“已完成”是否等价，需要有明确判断。
第三步：关联关系重建
输入是映射后的对象数据和来源系统中的关系记录，动作是按照父子层级、需求与缺陷关联、迭代归属等关系重新挂接对象，产出是关系完整的目标数据。重建顺序通常是先导入无依赖的对象，再按层级逐层导入，最后校验关联指向。
第四步：试迁移与差异核对
输入是映射规则和一小批代表性数据，动作是在目标系统中执行小批量迁移，比对条数、关键字段值和抽样明细，产出是差异清单和规则修订记录。试迁移的价值在于用较低成本暴露映射错误，特别是状态、选项值和关联关系方面的问题。
第五步：正式迁移与切换
输入是修订后的映射规则和切换计划，动作是在约定窗口内执行全量迁移，冻结来源系统写入，迁移完成后补齐窗口期内的增量数据，产出是目标系统中的完整数据和切换记录。冻结写入的时间长度需要根据数据量和业务节奏确定。
第六步：回退准备
输入是切换计划和来源系统状态，动作是保留来源系统只读访问或完整快照，明确回退触发条件，例如关键对象缺失、关联大面积错误或业务无法继续，产出是回退预案。回退准备在正式切换前完成，切换后按约定观察期决定是否解除。
在对象盘点和字段映射这两个环节，ONES 的迁移方案提供了可参照的处理范围。以 Jira 迁移到 ONES 的场景为例，迁移内容覆盖项目、工作项、状态、字段、流程、附件和历史记录，问题数据包括属性和属性值、附件、评论等信息，同时迁移用户、用户组和系统配置，包括问题类型、工作流、字段配置和权限配置。这些内容对应上文的对象类别，团队可以据此对照自己的盘点清单，确认哪些对象已有明确迁移路径、哪些需要单独确认。具体迁移范围仍以实际盘点和方案确认为准。
与普通数据导出、备份的区别
迁移、导出和备份都涉及数据搬运，但目标、关系处理和验证方式不同。用同一组维度对照，可以看清三者的边界。
| 对照维度 | 研发数据迁移 | 数据导出 | 数据备份 |
|---|---|---|---|
| 目标 | 目标系统可继续使用，业务在新系统中流转 | 把数据取出，用于分析、归档或交接 | 保留可恢复的数据副本，应对故障或误操作 |
| 结果形态 | 目标系统中的对象、关系和配置 | 文件、表格或结构化数据包 | 可还原的备份集 |
| 关系处理 | 重建父子层级、关联和归属关系 | 通常丢失或扁平化关系 | 按原系统结构整体保存，恢复时还原 |
| 验证方式 | 以目标系统内业务可用为验收，核对条数、关键字段和抽样明细 | 以导出完整性和文件可读为验收 | 以恢复演练结果为验收 |
三者可以组合使用。备份常作为迁移的回退手段，导出可以作为迁移前的数据留档或迁移后的核对样本。把导出当成迁移完成，问题往往在切换后才暴露：文件里有数据，但目标系统里没有可用的对象关系，团队无法按原有方式继续工作。
具体例子与常见误解
假设一个研发团队要把旧系统中的“订单中心”项目迁到新系统。这个项目包含 3 个迭代、约 400 条需求与任务、120 条缺陷、若干附件和评论。按对象和环节落地，处理顺序大致如下：
- 盘点阶段确认迁移范围为该项目全部工作项、3 个迭代、项目成员和近两年的评论附件，排除已归档的测试数据。
- 映射阶段建立需求、任务、缺陷、子任务的类型对应表，确认旧系统“已修复”对应新系统“待验证”，并列出自定义字段的选项值转换规则。
- 先导入迭代和版本，再导入无父级的需求，然后导入任务和子任务，最后导入缺陷并挂接关联需求。
- 试迁移选取一个迭代的数据执行，核对条数和状态分布，发现部分子任务父级指向为空，回到映射环节修正层级规则。
- 正式迁移在周末窗口执行，冻结旧系统写入，迁移完成后补齐窗口期新增的 15 条工作项。
- 旧系统保留只读访问两周，作为回退准备，观察期内确认新系统业务正常后解除。
这个示例是演示情景，实际项目的对象数量和顺序会随来源系统情况变化。
围绕迁移，有三个常见误解值得澄清。
误解一：导出全部数据就等于完成迁移。导出得到的是文件，目标系统中没有对象、没有关系、没有可继续流转的状态。迁移的验收发生在目标系统内，导出只是中间步骤。
误解二：字段名相同就无需映射。字段名相同不代表语义相同。状态、优先级和选项值在不同系统中可能有不同的取值集合和业务含义，直接按名称对应会造成统计口径偏差。映射需要处理取值转换规则，而不仅是字段名的对应。
误解三：迁移是一次性动作。正式切换前后往往存在增量数据，切换窗口内的新增和修改需要补齐；切换后还需要一段观察期核对业务可用性。把迁移视为一次性导入，容易遗漏增量数据和切换后的核对工作。
工作流定义与插件行为的迁移涉及流程引擎和扩展机制的适配，属于相邻主题，本文不展开。迁移完成后的验证方法与切换管理流程同样另有专门讨论，读者可按需查阅。
常见问题
研发数据迁移时，历史迭代归属应该保留当前状态还是保留变更过程？
这取决于迁移后团队如何使用迭代视图和统计报表。如果新系统主要按当前迭代查看工作项分布，保留当前归属即可；如果需要复盘每个迭代当时的范围和工作量，就要保留历史归属记录。两种口径对迁移的数据结构要求不同，建议在范围盘点阶段就与业务负责人确认，并写入映射规则，避免试迁移后再返工。
来源系统中的自定义字段很多，是否全部都要迁移？
不必全部迁移。可以先按使用频率和业务价值筛选：仍在用的字段优先迁移，长期为空或已被替代的字段可以只保留在来源系统的只读快照中。筛选结果要形成字段清单，并标注每个字段的迁移方式（迁移、合并、舍弃），作为后续核对依据。舍弃字段前建议确认没有报表或集成依赖它。
试迁移应该选多少数据、选哪些数据才有代表性？
试迁移的目标是暴露映射规则的问题，而不是追求数据量。建议选取一个完整迭代或一个典型项目，覆盖主要工作项类型、多层父子结构、跨类型关联、附件评论和自定义字段。数据量以能在较短时间内完成核对为准。核对时重点看条数是否一致、状态分布是否合理、关联指向是否正确，发现差异后回到映射环节修订规则再重试。
切换窗口内产生的新数据怎么处理？
正式迁移通常需要冻结来源系统写入，但冻结时间有限，窗口内仍可能有新增或修改。常见做法是在全量迁移完成后，按时间戳或变更记录补齐窗口期增量，再开放目标系统使用。冻结时长要根据数据量和业务节奏确定，并提前通知团队。补齐完成后需要再核对一次增量部分的条数和关键字段。
回退准备需要做到什么程度才算充分？
回退准备的核心是保证切换后出现严重问题时，团队仍能回到可工作的状态。常见做法是保留来源系统的只读访问或完整快照，并明确回退触发条件，例如关键对象整类缺失、关联大面积错误或业务无法继续。回退预案应在正式切换前完成，切换后按约定观察期决定是否解除。观察期长度可结合业务节奏和数据规模确定。
