研发数据迁移可以按“定范围—盘数据—建映射—试迁移—校验—切换与回退”六步推进。每一步都留下可核对的交付物：范围清单、输入检查表、字段映射表、试迁移记录、核验清单和回退预案。迁移方向、系统版本和对象范围要在动手前写清；同名字段含义不同、状态体系不一致、附件与评论归属，是映射阶段最需要提前处理的难点。下文按执行顺序展开，并在映射与核验环节说明 ONES 可承载的相关能力。
要点总览（TL;DR）
- 先写清来源系统、目标系统、版本和迁移对象清单，把排除项与确认人一并固定，迁移方向保持单向。
- 字段映射表至少包含源对象、源字段、源取值、目标对象、目标字段、转换规则和负责人；同名字段先取样本比对取值分布，再决定直接对应、值转换或拆分。
- 试迁移选取覆盖各工作项类型、各状态、含附件与评论的真实记录，先迁人员与组织等主数据，再迁工作项、测试用例、附件和评论。
- 核验按条数、字段抽样、关联关系、附件与评论四类进行，差异逐条登记并留存签字记录，未关闭的挂起项不进入下一批。
- 分批切换按业务影响从低到高推进，源系统在每批导出完成后进入只读冻结；条数差异超阈值、关键字段大面积错位或附件批量缺失时暂停并评估回退。
来源、目标与迁移对象范围怎么定
迁移范围决定后续所有工作量的边界。第一步要把来源系统、目标系统、各自版本和迁移对象清单固定在一页纸上，由业务负责人和系统管理员共同确认。范围一旦确认，新增对象走变更流程，避免迁移中途不断加需求。
范围清单至少写清四类信息：来源系统及其版本、目标系统及其版本、本期迁移对象、本期排除对象及确认人。迁移对象通常包括工作项（需求、任务、缺陷）、测试用例、迭代与版本、状态与优先级、人员与用户组、附件、评论和历史操作记录。排除项也要写明，例如已归档项目、测试环境数据、废弃自定义字段，并注明由谁确认排除。
迁移方向必须书面确认，不能颠倒。来源系统是数据提供方，目标系统是数据接收方，试迁移和正式迁移都按同一方向执行。若存在双向同步或回迁需求，应作为独立事项另行评估，不混入本次迁移范围。
| 范围清单项 | 填写内容示例 | 确认人 |
|---|---|---|
| 来源系统与版本 | Jira Data Center，版本号待管理员提供 | 系统管理员 |
| 目标系统与版本 | ONES Project，版本以实际部署为准 | 系统管理员 |
| 迁移对象 | 需求、任务、缺陷、测试用例、迭代、附件、评论、人员 | 研发负责人 |
| 本期排除项 | 已归档项目、测试环境数据、废弃字段 | 项目经理 |
| 迁移方向 | 来源系统 → 目标系统，单向 | 项目发起人 |
迁移前需要准备哪些输入与依赖
范围确定后，进入执行前置条件检查。迁移启动前必须到位的输入包括账号权限、导出能力、字段字典、人员名单和迁移窗口安排。任何一项缺失，都可能导致试迁移中断或映射规则返工。
权限方面，需要确认源系统的数据导出权限（含附件下载、评论读取、历史记录访问）和目标系统的数据导入权限（含工作项创建、附件上传、用户与用户组管理）。权限不足时，提前申请并记录审批人，避免迁移当天才发现无法导出。
资料方面，准备源系统的字段字典、状态字典、优先级字典和人员名单。字段字典要列出每个字段的名称、类型、取值范围和业务含义；状态字典要列出全部状态值及流转关系；人员名单要包含账号、姓名、所属团队和在职状态。目标系统侧则要确认字段类型、必填约束和取值枚举，尤其是目标系统要求必填而源系统允许为空的字段。
人员方面，指定业务方字段含义确认人，负责判断同名字段是否同义、状态如何归并。迁移窗口与冻结期也要提前排定：冻结期内源系统停止新增和修改数据，只读运行，冻结开始时间以最后一批数据导出完成为准。
- 源系统导出权限与目标系统导入权限已开通并记录审批人
- 字段字典、状态字典、优先级字典、人员名单已收集
- 目标系统字段类型与必填约束已核对
- 业务方字段含义确认人已指定
- 迁移窗口、冻结期和每批观察期已排入日程
字段与数据怎么映射：同名字段含义不同怎么办
映射表是迁移的核心交付物。建议至少包含七列：源对象、源字段、源取值、目标对象、目标字段、转换规则、负责人。每一行对应一条映射规则，转换规则写清直接对应、值转换、拆分合并还是挂起待确认。
| 源对象 | 源字段 | 源取值 | 目标对象 | 目标字段 | 转换规则 | 负责人 |
|---|---|---|---|---|---|---|
| 缺陷 | 状态 | Open / In Progress / Resolved / Closed | 缺陷 | 状态 | Resolved 映射为“待验证”，Closed 映射为“已关闭” | 业务确认人 |
| 需求 | 优先级 | P0 / P1 / P2 / P3 | 需求 | 优先级 | P0→最高，P1→高，P2→中，P3→低 | 产品负责人 |
| 任务 | 经办人 | 账号或姓名 | 任务 | 负责人 | 按人员名单账号匹配，离职人员挂起 | 系统管理员 |
| 全部 | 附件 | 文件及上传人 | 全部 | 附件 | 随主记录迁移，保留上传人和上传时间 | 系统管理员 |
同名字段含义不同时，先取样本比对取值分布，再决定处理方式。例如源系统的“优先级”按紧急程度划分，目标系统的“优先级”按业务价值划分，两者名称相同但语义不同。做法是从各类型工作项中抽取样本，统计源字段的取值分布，与业务确认人逐项对照目标字段的取值定义，确定是直接对应、值转换还是拆成两个字段分别承载。样本比对要覆盖高频值和边界值，避免只看少数记录就下结论。
状态与优先级体系不一致时，先列出源系统全部取值及分布，再与业务方确认目标取值和归并规则。归并要保留业务含义差异，例如“已解决”和“已关闭”在源系统代表不同阶段，就不能合并成同一个目标状态。无法映射的字段进入挂起清单，注明挂起原因、影响范围和确认人，确认后再补入映射表，不带着未决规则进入试迁移。
人员、附件和评论的归属映射同样要写进映射表。人员按账号或唯一标识匹配，匹配不上的离职人员单独列出，其历史记录保留原姓名文本；附件随主记录迁移，保留上传人和上传时间；评论保留作者、时间和正文，作者无法匹配时以文本形式保留。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、附件和历史记录，问题数据迁移包括属性和属性值、附件、评论等信息，可作为映射落地时的承载参考；具体字段映射冲突的处理规则，需在实施前向原厂确认。
试迁移怎么做：小批量验证流程
试迁移的目的是用一小批真实数据验证映射规则，暴露问题后再进入全量。样本选取要覆盖各工作项类型、各状态、含附件与评论的记录，并包含至少一条关联关系复杂的需求（含子任务、关联缺陷、所属迭代）。样本量以能覆盖全部映射规则为准，不必追求数量。
执行顺序先主数据后业务数据：先迁移人员、用户组和组织结构，再迁移项目、迭代等工作项容器，最后迁移工作项、测试用例、附件和评论。主数据先到位，业务数据的负责人、经办人字段才有可匹配的对象。
试迁移过程中逐条记录问题，形成问题清单，内容包括问题现象、涉及字段或对象、影响条数、初步原因和修正动作。修正动作回流到映射表或导入脚本，修正后重新跑一遍受影响的样本，确认问题关闭。试迁移通过的标准是：样本范围内条数一致、关键字段值一致、关联关系完整、附件与评论可打开。达到标准后才进入分批全量，未通过则继续修正，不压缩验证时间。
迁移结果怎么核验：证据与通过标准
核验按条数、字段值、关联关系和附件评论四类进行，每类都有可逐项核对的通过标准，核验结果留存证据并签字确认。
| 核验类别 | 核对方法 | 通过标准 | 差异处理 |
|---|---|---|---|
| 条数核对 | 源与目标各类型记录数比对 | 各类型条数一致，差异在约定阈值内 | 逐条登记缺失或重复记录 |
| 字段值抽样 | 按类型抽取样本比对字段值 | 关键字段一致，非关键字段差异有说明 | 形成差异清单并确认是否修正 |
| 关联关系 | 核对父子项、关联需求与缺陷、迭代归属 | 关联关系完整，无孤立记录 | 补建关联或登记为已知差异 |
| 附件与评论 | 抽查附件可下载、评论作者与时间正确 | 抽查全部可打开，作者时间一致 | 缺失附件重新导入并复核 |
条数核对以导出时的源系统快照为准，冻结期内的数据不再变化，比对才有意义。字段值抽样要覆盖每个映射规则至少一条记录，重点检查经过转换和拆分的字段。关联关系核对关注父子项是否挂接正确、需求与缺陷的关联是否保留、迭代归属是否落在正确周期。附件与评论按比例抽查，附件要实际打开确认内容完整，评论要核对作者和时间。
核验证据包括条数比对表、抽样记录、差异清单和签字确认页。差异逐条登记处理结论：已修正、确认可接受或挂起待定。挂起项要明确责任人和关闭时间，未关闭的挂起项不能随批次切换带入下一阶段。ONES 的 Confluence 迁移可将空间、页面、附件和权限结构迁移到 ONES Wiki，并保留原有知识组织方式，知识库内容的核验可参照附件与页面完整性口径执行；迁移工具是否提供条数校验和差异报告，需在试迁移阶段实际确认。
切换节奏与回退、停止条件
试迁移和核验通过后进入分批切换。分批顺序建议按业务影响从低到高：先切一个非核心项目或一个团队，观察期内确认日常使用正常，再逐步扩大批次。每批设置观察期，观察期内保留源系统只读访问，便于对照核查。
源系统在切换前进入只读冻结，冻结时间点以该批数据导出完成为准。冻结后源系统不再接受新增和修改，所有变更在目标系统进行。冻结通知要提前发给全部使用方，写明冻结开始时间、影响范围和联系人。
触发暂停或回退的条件要提前写定，例如：条数差异超过约定阈值、关键字段大面积错位、附件批量缺失、关联关系大面积断裂。出现上述情况时暂停当前批次，评估是修正后重跑还是回退。回退时目标系统该批次数据标记为作废或清理，源系统解除只读、恢复写入，并通知使用方回到源系统继续工作。回退决策由项目发起人和业务负责人共同确认，记录决策时间和依据。
切换完成后做收尾：确认各批次观察期结束、挂起差异全部关闭、使用方反馈的问题处理完毕，再安排旧系统下线。下线前保留源系统只读备份和导出数据包，下线确认由系统管理员和业务负责人签字。ONES 建议把迁移工具、原厂服务和分阶段切换结合起来，并在正式迁移前确认数据范围、功能匹配和系统适配，以降低数据丢失或业务中断风险；该建议不构成对迁移结果的保证，实际切换节奏仍以试迁移和核验结果为准。
常见问题
迁移对象里有已归档项目和废弃自定义字段，要不要一起迁？
默认不迁，但要在范围清单里写明排除项和确认人。已归档项目通常只保留查询价值，废弃字段在目标系统没有对应承载位置，强行迁移只会增加映射和核验工作量。如果业务方后续需要查历史，可以在旧系统保留只读访问或导出数据包，作为过渡期的查询入口。
排除项确认后走变更流程管理：迁移中途新增对象，需要重新评估映射规则和试迁移样本，不能直接插入全量批次。
源系统里同一个字段在不同项目下含义不一样，映射表怎么建？
按“项目范围＋字段”拆行建映射，不要用一个全局规则覆盖所有项目。做法是先按项目分组抽取样本，统计同一字段在各项目下的取值分布，再与业务确认人逐组确认目标字段和转换规则。差异较大的项目单独设转换规则，并在映射表备注列写明适用范围。
如果差异来自字段复用而非业务含义不同，可以在目标系统拆成两个字段分别承载，避免迁移后数据混在一起难以区分。
试迁移通过了，全量迁移时还需要再核验一遍吗？
需要，而且核验口径保持一致。试迁移验证的是映射规则本身，全量迁移还要验证数据在分批导出、传输和导入过程中没有丢失或错位。每批全量完成后都按条数、字段抽样、关联关系、附件与评论四类核对，差异逐条登记处理结论。
试迁移的样本记录在全量时会被覆盖或重复导入，导入前要确认去重规则，避免同一工作项出现两条记录。
源系统冻结后发现有数据要补，怎么处理？
冻结期内源系统只读，补数据只能在目标系统进行，或作为差异记录挂起。若遗漏的是关键业务数据，先评估影响范围：只影响个别记录时，在目标系统手工补录并登记来源；影响整批数据时，暂停当前批次，解除冻结补导后重新核验。
冻结通知要提前发出，写明开始时间、影响范围和联系人，让使用方在冻结前完成必要的收尾操作，减少冻结后的补录需求。
离职人员的历史工作项和评论怎么处理？
人员映射按账号或唯一标识匹配，匹配不上的离职人员单独列出。其历史工作项的负责人字段可以保留原姓名文本，或统一转给接手人并在描述中注明原负责人；评论保留作者姓名和时间，作者账号无法匹配时以文本形式保留，保证历史记录可读。
这部分规则要写进映射表并由业务确认人签字，避免迁移后出现大量无主记录。
