研发数据迁移的核心，是把源系统中的工作项、字段、用户身份、附件和链接关系，按可核验的映射规则搬到目标系统，并用试迁移验证后再切换。推进顺序通常是：盘点清理源数据、确定范围与冻结窗口、建立实体和字段及用户身份映射、小批量试迁移、核验结果并决定是否切换。本文按这一顺序给出可填写、可检查的操作方法，适合研发效能或项目管理角色在迁移准备与执行阶段使用。
要点总览（TL;DR）
- 研发数据迁移按“盘点清理—范围与冻结—实体字段与身份映射—小批量试迁移—核验—切换或回退”推进，映射表和核验证据是贯穿全程的两件核心交付物。
- 同名字段先做语义比对，再由字段口径负责人判定直接映射、转换映射或拆分映射；枚举与状态值逐值建立对照表，状态流转语义需业务方确认。
- 用户身份以邮箱或账号目录 ID 等稳定唯一标识为主键，姓名仅作辅助核对，重名与离职人员单独列出处理策略。
- 附件按“源项目/源工作项标识/原文件名”组织并靠工作项唯一标识重建关联；链接与父子关系先导出关系清单再做类型对照。
- 试迁移覆盖各实体类型、枚举全部取值和边界值，问题回写映射表形成闭环；数量差异、关键字段错位、附件缺失超过预设阈值时暂停并回退到执行前快照。
迁移范围：哪些研发数据要搬，哪些先不搬
迁移启动前先把范围写清楚，后续的映射、试迁移和核验才有统一口径。范围清单至少包含四项信息：源系统与目标系统及其版本、迁移对象及数量级、不纳入本次迁移的内容、数据冻结时点。版本要写到具体版本号，因为导出能力、字段类型和附件处理方式可能随版本变化。
迁移对象按数据形态分五类登记：工作项（需求、任务、缺陷、迭代等）、字段（含自定义字段与属性值）、用户与用户组、附件、对象之间的链接与引用关系。每一类记录来源版本、预计条数或容量、负责人。数量级用于后续核验比对，不必在盘点阶段追求精确到个位。
不纳入本次迁移的内容要写明归属，避免执行中被临时追加。常见做法是把工作流与插件行为迁移、历史操作日志、报表配置等列入后续阶段或单独方案，并在范围清单中标注责任人和计划时点。范围一旦确认，新增对象需走变更记录，而不是口头补充。
冻结时点决定增量边界。建议在正式全量迁移前设定一个明确的时间点，此后源系统停止新增和修改业务数据，只允许查询。冻结窗口的长度取决于全量迁移耗时和核验耗时，需要在试迁移后根据实际速度估算。冻结期间产生的少量数据，按增量处理方案单独登记。
| 范围清单字段 | 填写示例 | 用途 |
|---|---|---|
| 源系统 / 版本 | 源系统名称 + 版本号 | 确认导出能力与字段类型 |
| 目标系统 / 版本 | 目标系统名称 + 版本号 | 确认导入模板与容量 |
| 迁移对象 | 工作项、字段、用户、附件、链接 | 逐类登记数量级 |
| 不迁移内容 | 工作流行为、插件配置等 | 标注归属与计划时点 |
| 冻结时点 | 具体日期与时刻 | 界定增量边界 |
迁移前要准备什么：输入清单与依赖
映射工作开始前，把输入和依赖逐项确认到位，能显著减少返工。以下检查表按“是否具备、负责人、确认日期”三列使用，全部确认后再进入映射表编制。
- 源系统导出能力与格式：确认可导出的对象类型、导出文件格式（如表格文件、数据包）、单次导出量限制，以及附件能否批量获取。
- 目标系统导入模板与字段容量：取得目标系统的导入模板，核对字段类型、必填项、单字段长度和枚举取值范围。容量限制不明确时向原厂确认，不凭经验假设。
- 用户身份来源：确定以账号目录还是人员名单为准，导出包含唯一标识（邮箱或账号 ID）、姓名、所属部门、在职状态的清单。
- 附件存储位置与访问权限：确认附件原始存放位置、总容量、下载权限，以及迁移执行账号是否具备读取权限。
- 字段口径负责人：为每个业务域指定一名能拍板字段含义的人，负责在同名字段含义冲突时给出结论。
这些依赖中，字段口径负责人最容易被忽略却影响最大。字段映射的争议往往不是技术问题，而是两个系统对同一名称的业务定义不同，需要业务方而非实施人员裁定。
字段与实体映射：同名字段含义不同怎么处理
映射分三层：实体对应、字段对应、用户身份对应。三层都落到同一张映射表里维护，试迁移时逐行核对。
实体对应关系
先确定源系统的需求、任务、缺陷、迭代分别对应目标系统的哪类工作项。对应关系可以是一对一，也可以是多对一（例如源系统的多种任务类型合并为目标系统的一种工作项类型），但合并后要记录原类型值，避免丢失分类信息。实体对应表建议包含：源实体、目标实体、对应方式、是否保留原类型字段。
同名字段含义不同的识别与处理
识别方法是对每个同名字段做语义比对：取源字段的定义、取值范围和典型样例，与目标字段逐项对照。出现以下情况即判定为含义不同：取值范围不一致、计量单位不同、一个字段承载了多个业务概念、必填规则相反。处理策略有三种：直接映射（语义一致）、转换映射（语义可通过规则换算）、拆分映射（一个源字段拆到多个目标字段，或反之）。判定由字段口径负责人签字确认，写入映射表备注。
枚举值与状态值转换
枚举和状态是最容易出错的部分。为每个枚举字段建立取值对照表，逐值列出源值、目标值、转换规则。源系统存在而目标系统没有的取值，需要决定是归入某个默认值、新增目标枚举项，还是保留在备注字段中。状态值还要注意流转语义：源系统的“已关闭”与目标系统的“已完成”是否等价，需业务方确认后再定。
用户身份映射
以稳定唯一标识作为主键，优先使用邮箱或账号目录 ID，姓名仅作辅助核对。重名人员单独列出，用部门或工号区分。离职人员在源系统中仍可能作为历史工作项的创建人或处理人出现，需要为其保留占位账号或映射到统一的归档账号，具体方式与目标系统管理员确认。用户组按成员关系整体映射，映射后核对组成员数量。
映射表结构
| 列名 | 说明 |
|---|---|
| 源实体 / 源字段 | 源系统中的对象与字段名 |
| 目标实体 / 目标字段 | 目标系统中的对应对象与字段 |
| 字段类型 | 文本、数值、日期、枚举、人员等 |
| 转换规则 | 直接映射、取值对照、公式换算、拆分或合并 |
| 是否必填 | 目标系统侧的必填约束 |
| 口径负责人 | 对该字段语义负责的人员 |
| 确认状态 | 待确认、已确认、试迁移待验证 |
| 备注 | 边界值、例外情况、待确认问题 |
映射表按版本管理，每次修改记录修改人和日期。试迁移发现的问题回写到对应行，形成“问题—修改—复验”的闭环。
在目标系统侧，字段配置能力决定了映射表能否落地。以 ONES 为例，其 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，迁移问题数据时包含属性和属性值、附件、评论等信息，并迁移用户、用户组及问题类型、字段配置等系统配置。这些能力可作为映射表设计时的参照，具体字段类型支持边界和导入模板结构需与原厂确认后再定稿。
历史附件与链接关系如何保留
附件和链接属于非结构化数据与关系数据，处理方式与字段映射不同，需要单独方案。
附件批量迁移先确定路径与命名规则。建议按“源项目/源工作项标识/原文件名”组织目录，文件名保持原样，重名文件追加序号。迁移后附件与工作项的关联通过工作项唯一标识重建，而不是依赖文件名匹配。迁移前后各统计一次附件总数和总容量，作为核验依据。单个附件的大小上限和允许的文件类型以目标系统实际限制为准。
工作项之间的链接、父子关系和引用关系，先导出关系清单，包含源对象标识、目标对象标识、关系类型。关系类型需要做对照：源系统的“阻塞”“关联”“复制”等关系在目标系统中是否有对应类型，没有对应类型的，决定归入通用关联还是记录在备注中。父子关系通常可以整体保留，但跨项目的父子关系要确认目标系统的项目边界是否允许。
失效链接和外部链接单独处理。指向已删除对象的内部链接标记为失效并记录清单；指向外部系统的链接保留原始地址，迁移后抽查可达性。引用关系（如评论中提及的工作项编号）在编号规则变化时需要做文本替换或保留原编号并附说明，选择哪种方式由业务方确认。
ONES 的迁移方案在 Jira 场景中覆盖附件和历史记录，Confluence 迁移到 ONES Wiki 时支持页面正文、附件、图片、常用宏及批注的迁移，并提供批量迁移与数据包导入两种方式。工作项之间链接与父子关系的具体保留方式，资料未作说明，实施前应向原厂确认。
试迁移怎么做：小批量验证映射规则
试迁移的目的是用少量数据验证映射表，把问题暴露在全量执行之前。抽样要覆盖各实体类型、典型字段和边界值，而不是随机取几条了事。
抽样原则可以这样执行：每种实体类型至少抽取一批样本；每个枚举字段覆盖全部取值，包括只在历史数据中出现的低频值；边界值单独抽样，如超长文本、空值、特殊字符、最大附件；跨项目链接和跨类型父子关系各抽一组。样本量以能在半天内完成核对为宜，具体条数根据实体种类确定。
试迁移按批次划分，建议顺序为：第一批用户与用户组，第二批单项目工作项与字段，第三批附件，第四批链接关系，第五批多项目混合样本。每批完成后先核对再进入下一批，避免问题叠加。
问题记录表与映射表联动使用，字段包括：问题编号、所属批次、涉及实体与字段、现象描述、判定原因（映射规则错误、源数据异常、目标配置缺失）、处理方式、映射表修改行号、复验结果。试迁移期间源系统仍在产生新数据，这部分增量单独登记，不混入试迁移样本，待冻结后按增量方案处理。
| 批次 | 样本内容 | 完成标志 |
|---|---|---|
| 第一批 | 用户与用户组 | 成员数量与身份对应核对通过 |
| 第二批 | 单项目工作项与字段 | 字段值抽检无未解释差异 |
| 第三批 | 附件 | 数量、容量、可下载性核对通过 |
| 第四批 | 链接与父子关系 | 关系清单逐条可达 |
| 第五批 | 多项目混合样本 | 跨项目关系与边界值核对通过 |
核验与证据：迁移结果怎么确认
核验面向结果确认，与试迁移的过程验证分开。核验清单按“核验项、方法、通过标准、证据形式、责任人”组织，每项留存证据。
- 数量核验：各实体迁移前后条数比对，工作项、用户、附件、链接关系分别统计。差异逐条说明原因，未解释的差异不计入通过。
- 字段值抽检：按实体类型分层抽样，覆盖枚举、日期、人员、数值字段，记录抽检条数、差异条数和差异明细。
- 附件可下载性：随机抽取附件实际下载打开，核对文件内容与源文件一致，统计失败数量。
- 链接可达性：按关系清单抽查链接目标是否存在、关系类型是否正确，外部链接抽查可达性。
证据留存形式建议统一：数量比对用导出表格存档，字段抽检用带样本编号的核对表，附件与链接检查用截图或检查记录，每份证据标注执行人、执行时间和对应批次。证据由核验责任人签字，作为切换决策的输入。
回退与停止条件：什么情况下暂停迁移
停止条件在迁移前量化，执行中按阈值判断，避免临时争论。典型信号包括：数量差异超过预设阈值（如某类实体差异比例超过约定值）、关键字段大面积错位（如状态或负责人字段错误比例超出抽检容忍度）、附件缺失数量超过约定上限、用户身份映射出现批量错误。
回退点设置在每次全量执行之前。执行前对目标系统做一次快照或记录当前状态，确保可以回到迁移前状态。源系统在切换完成并稳定运行一段时间前保持只读保留，保留周期在范围清单中写明，期间不删除源数据。
增量同步中断后的恢复方式要提前约定：记录中断时点、已同步到的数据标识，恢复时从该标识之后重新同步，并核对中断期间的数据是否完整。切换前的最终确认事项包括：核验清单全部通过并有证据、停止条件未触发、回退点可用、源系统保留周期已确认、业务方完成验收签字。任一项未满足，推迟切换而不是带问题上线。
ONES 的迁移方案建议把迁移工具、原厂服务和分阶段切换结合，在正式迁移前确认数据范围、功能匹配和系统适配，并以数据完整、业务连续和系统稳定为目标。这一思路与上述停止条件和回退安排一致：分阶段推进、逐段核验，把风险控制在可回退的范围内。
常见问题
源系统还在使用，冻结窗口应该设多长？
冻结窗口由全量迁移耗时和核验耗时相加决定，建议先用试迁移测出实际速度再估算，不要凭经验拍一个天数。窗口内源系统只允许查询，新增和修改的业务数据按增量方案单独登记。窗口过长会影响业务正常开展，可以在范围清单里写明冻结起止时刻和期间的数据处理方式，让业务方提前安排。
源系统里有大量历史遗留字段，全部映射过去是否必要？
不必全部映射。盘点阶段可以按使用情况给字段分级：仍被报表或业务查询使用的字段优先映射；长期无人填写、只承载历史备注的字段，可以合并到目标系统的备注或描述字段，或只保留在归档导出文件中。判定由字段口径负责人确认，并在映射表备注里写明取舍理由，避免后续追溯时找不到依据。
试迁移通过后，正式全量迁移还需要再核验一遍吗？
需要。试迁移验证的是映射规则，全量迁移验证的是执行结果，两者对象不同。全量执行后仍要按核验清单做数量比对、字段抽检、附件可下载性和链接可达性检查，并留存证据。试迁移的通过结论可以作为映射表定稿的依据，不能替代全量结果的确认。
迁移过程中发现映射规则有误，已经迁过去的数据怎么处理？
先暂停当前批次，把问题回写到映射表对应行，记录现象、判定原因和修改内容，再决定处理方式：影响范围小的，修正规则后对该批数据重迁；影响范围大的，回到最近的回退点重新执行。这也是回退点要设在每次全量执行之前的原因，保证可以回到迁移前状态而不必逐条修补。
ONES 作为目标系统时，迁移前需要向原厂确认哪些信息？
建议至少确认四类信息：迁移工具对源系统版本、数据量级和字段类型的支持边界；增量数据同步的机制；工作项之间链接、父子关系与引用关系的保留方式；导入模板结构、字段容量限制以及试迁移和回退安排。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，迁移问题数据时包含属性和属性值、附件、评论等信息，并迁移用户、用户组及问题类型、字段配置等系统配置；Confluence 迁移到 ONES Wiki 时支持页面正文、附件、图片、常用宏及批注，提供批量迁移与数据包导入两种方式。上述支持边界仍需与原厂核实后再写入范围清单和映射表。
