研发数据迁移通常按“定范围—盘数据—做映射—试迁移—核验—切换与回退”推进，难点集中在字段映射和结果核验：同名字段含义不同、状态体系不一致、人员与权限需要重新对应，都会影响迁移后的可用性。本文按这六个阶段给出可落地的清单、映射表和核验标准，并在字段配置与迁移衔接处说明ONES可承载的工作。适用于从Jira、Confluence等系统迁往新平台，或在新旧系统之间做阶段性数据搬迁的研发团队。
要点总览（TL;DR）
- 先定“来源—目标—对象”范围清单，把工作项、迭代、状态、字段、附件、评论、人员与权限逐项勾选并标注数量级；工作流配置与插件行为单独评估，不默认随数据等价迁移。
- 字段映射按语义对齐而非名称对齐：建立含源字段、目标字段、类型、必填、转换规则和无法映射处理方式的映射表，枚举值建完整取值对照表，无法对应的值设默认值并规定人工确认。
- 试迁移样本覆盖主要工作项类型、典型状态和带附件、带关联关系的记录，按基础数据→工作项→关联与附件的顺序分批执行，每批记录批次号、条数、执行人和结果。
- 核验以数量比对、关键字段抽样、关联关系与附件完整性为主，证据留存并签字确认；不通过时按问题类型回到导出、映射或存储环节修正后重迁受影响批次。
- 切换前冻结业务并处理最终增量，提前写定回退触发条件与回退窗口，切换后设观察期并安排问题响应人和响应时限。
迁移范围怎么定：来源、目标与对象清单
范围界定的产出是一张“来源—目标—对象”清单，写清从哪个系统、哪个版本迁到哪个系统、迁哪些数据对象。这张清单是后续映射、试迁移和核验的共同基准，范围不清会直接导致核验时无法判断是否迁全。
来源侧要记录系统名称与版本号，目标侧同样记录产品与版本。版本信息影响导出方式、字段可用性和附件处理方式，缺失版本记录的迁移计划在试迁移阶段容易返工。若涉及多个来源系统（例如工作项在Jira、文档在Confluence），按来源分别列清单，不要合并成一张笼统的表。
数据对象清单建议按下表逐项勾选，并标注数量级：
| 对象类别 | 具体内容 | 是否本次迁移 | 预估条数 |
|---|---|---|---|
| 工作项 | 需求、任务、缺陷、子任务等 | ||
| 迭代与版本 | 迭代周期、版本号、发布记录 | ||
| 状态与流转结果 | 工作项当前状态、历史状态记录 | ||
| 字段与属性值 | 自定义字段、枚举值、文本与数值属性 | ||
| 附件 | 文件、图片、日志 | ||
| 评论与历史记录 | 评论正文、操作历史 | ||
| 人员与权限 | 用户、用户组、项目权限、空间权限 | ||
| 文档页面 | 页面正文、附件、批注（如涉及） |
同时要明确写出不在本次范围的内容。工作流配置、插件行为、报表与看板布局属于配置与扩展层面，是否随数据一并处理需要单独评估，不能默认随数据迁移自动等价。插件与定制场景尤其不宜假设可一一对应，迁移前应逐项梳理实际使用情况，评估替代方案或人工重建。把这些内容列进“不在范围”栏，可以避免验收时对“迁移完整”产生分歧。
ONES的Jira迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录展开，目标是保持研发过程连续；从Jira迁移到ONES Project时，迁移内容还包含用户、用户组以及问题类型、工作流、字段配置、权限配置等系统配置。这说明配置类内容在部分方案中会纳入迁移范围，具体取舍仍需在迁移前与实施方逐项确认，并以确认结果写入范围清单。
迁移前要准备哪些输入与依赖
启动迁移前需要备齐四类输入：源系统的导出权限与导出方式、目标系统的基础配置、对照字典、以及迁移窗口与业务冻结安排。缺任何一项都会让试迁移无法按计划开始。
- 源系统导出权限与方式：确认账号具备导出工作项、附件、评论和用户信息的权限，确认导出格式（数据库备份、API导出、平台自带导出包等）以及导出是否包含历史记录。导出权限不足是试迁移最常见的阻塞点，应提前申请并做一次小规模导出验证。
- 目标系统基础配置：目标侧的项目、字段、状态、人员与权限需要先建好骨架。字段要先定义类型和必填规则，状态要先确定状态集，人员和用户组要先建立，否则映射表没有可对齐的目标对象。
- 字段字典与对照表：整理源系统的字段清单（名称、类型、取值范围、是否必填）、状态定义与流转含义、人员账号对照表（源账号—目标账号—所属组）。人员对照表要覆盖离职账号和历史账号的处理方式。
- 迁移窗口与冻结安排：确定试迁移和正式迁移的时间段，明确冻结期间源系统是否允许新增或修改数据，以及冻结期间业务如何记录临时需求。冻结安排要与业务负责人共同确认，不能由技术侧单方面决定。
把上述内容做成一张检查表，逐项标注“已具备/待补齐/负责人/截止时间”，在试迁移开始前完成全部勾选。检查表同时作为迁移启动的准入条件，未完成项要写明风险和对迁移结果的影响。
字段映射怎么做：同名字段含义不同怎么处理
字段映射的核心原则是按语义对齐，而不是按名称对齐。两个系统里都叫“优先级”的字段，取值可能一个是五级、一个是三级；都叫“状态”的字段，一个包含“待验证”，另一个没有对应状态。映射表要记录每个字段的业务含义、取值范围和转换规则，让执行人和核验人都能按同一份规则判断结果是否正确。
字段映射表建议包含以下列：
| 源字段 | 源类型/取值 | 目标字段 | 目标类型/取值 | 是否必填 | 转换规则 | 无法映射时处理 |
|---|---|---|---|---|---|---|
| 优先级 | 枚举：最高/高/中/低/最低 | 优先级 | 枚举：高/中/低 | 是 | 最高、高→高；中→中；低、最低→低 | 记录原值到备注字段 |
| 状态 | 枚举：待办/进行中/待验证/已完成 | 状态 | 枚举：未开始/处理中/已完成 | 是 | 待办→未开始；进行中、待验证→处理中；已完成→已完成 | 待验证项人工确认归属 |
| 负责人 | 用户账号 | 负责人 | 用户账号 | 是 | 按人员对照表转换 | 离职账号转至项目公共账号并标记 |
枚举值映射要建立完整的取值对照表，覆盖源侧所有出现过的值，包括历史遗留值和空值。对无法一一对应的值，设定默认值并规定人工确认规则：例如“待验证”状态在目标侧没有对应项时，先映射为“处理中”，同时在备注中保留原状态，由业务负责人在核验阶段逐条确认。每一条转换决策都要写入映射表，避免执行时凭个人判断处理。
人员与权限映射需要单独一张对照表，处理账号改名、离职、跨组调动的情况。附件映射要确认目标系统的附件大小限制和存储方式，超大附件或特殊格式需要提前测试。关联关系映射（工作项之间的父子、关联、阻塞关系）要确认目标系统支持的关系类型，源侧存在而目标侧没有的关系类型，记录为待人工处理项。
无法映射的字段和记录要集中登记，形成待确认清单，由业务负责人逐项确认处理方式：转换、丢弃并记录、或保留在备注字段。清单确认完成后才能进入试迁移，未确认项带入试迁移会导致核验标准不清晰。
在ONES中，工作项字段、状态和权限配置可以在目标项目中先行定义，迁移时按已确认的映射表对齐；ONES的Jira迁移方案涵盖字段、状态、附件、评论和历史记录，Confluence迁移到ONES Wiki支持页面正文、附件、图片、常用宏及批注，并包含用户、用户组、空间权限与页面权限。常用宏的对应程度需要逐项评估，映射表中应为每个宏标注目标侧的呈现方式。
试迁移怎么执行：样本选择与分批策略
试迁移的目的是用少量真实数据验证映射规则是否成立，而不是提前完成正式迁移。样本要覆盖主要工作项类型、典型状态和带附件、带关联关系的记录，只迁几条同类型数据无法暴露映射冲突。
样本选取建议按以下维度各取若干条：每种工作项类型至少覆盖一条；每种状态至少出现一次；包含带多个附件的记录、带评论和历史记录的记录、存在父子或关联关系的记录；包含负责人已离职或跨组的记录。样本总量控制在可人工逐条核对的范围内，便于发现字段值偏差。
执行顺序按依赖关系推进：
- 基础数据：用户、用户组、项目、字段与状态定义。
- 工作项主体：按类型分批迁移，先迁字段简单的类型，再迁自定义字段多的类型。
- 关联与附件：在工作项主体迁移完成后处理父子关系、关联关系和附件、评论。
每批次记录批次号、迁移对象、条数、执行时间、执行人和结果。批次记录是后续核验和问题追溯的依据，也是正式迁移分批推进的模板。试迁移中发现映射问题时，回到映射表修正规则，修正后重新执行受影响批次，并在批次记录中注明修正内容，避免同一问题在正式迁移中重复出现。
正式迁移按试迁移验证过的批次划分推进，每批完成后做一次小范围核验再进入下一批。分批的粒度以单批可在计划窗口内完成、且失败时影响范围可控为准，具体批次数量根据数据量和窗口长度确定。
迁移结果怎么核验：证据与通过标准
核验要回答三个问题：数据是否迁全、字段值是否正确、关联与附件是否完整。核验结论以书面报告和签字确认为准，口头确认不作为通过依据。
| 核验项 | 核验方法 | 通过标准 | 证据形式 |
|---|---|---|---|
| 数量核验 | 按对象类型比对源侧导出条数与目标侧入库条数 | 各类型条数一致，差异项有逐条说明 | 条数比对表 |
| 字段值核验 | 按类型抽样比对关键字段与枚举值，覆盖所有映射规则 | 抽样记录字段值与映射表一致，偏差项已修正或登记 | 抽样比对记录 |
| 关联关系核验 | 抽查父子、关联、阻塞关系在目标侧的呈现 | 关系数量与方向正确，缺失项有处理记录 | 关系抽查清单 |
| 附件完整性 | 比对附件数量、文件名和可打开性 | 附件数量一致，抽样文件可正常打开 | 附件核对记录 |
| 评论与历史 | 抽查评论条数与内容、历史记录是否保留 | 评论条数一致，历史记录可查 | 抽查记录 |
核验证据由执行人整理、业务负责人确认，双方在核验报告上签字。核验不通过时，按问题类型分流：数量差异回到导出与入库环节排查；字段值偏差回到映射表修正后重迁受影响批次；附件缺失检查存储与大小限制；关联关系缺失检查关系类型支持情况。修正后重新核验，直到全部核验项达到通过标准。
ONES建议在正式迁移前确认数据范围、功能匹配和系统适配，并把迁移工具、原厂服务和分阶段切换结合起来，以降低数据丢失或业务中断的风险。这一建议对应到核验环节，就是把范围清单、映射表和核验报告作为三道检查关口，每道关口有明确的责任人和确认记录。
切换与回退：什么时候停、怎么退
切换时点应安排在核验通过之后，并在切换前完成业务冻结和最终增量处理。冻结期间源系统停止新增和修改数据，技术侧处理冻结前产生的最后一批增量，确保切换后目标系统数据与源系统一致。冻结时长根据增量处理速度确定，并在切换计划中写明起止时间。
回退触发条件要提前写定，常见的有三类：核验未通过且无法在窗口内修正；关键数据缺失（如核心项目的工作项或附件大面积缺失）；切换后业务无法正常开展（如关键流程在目标系统无法执行）。触发条件应具体到可判断的程度，例如“核心项目工作项缺失超过约定比例”或“关键审批流程无法在目标系统走通”，避免事后争议。
回退方式与回退窗口需要在切换前确认：回退到源系统的数据恢复方式、回退操作的责任人、回退窗口的时长，以及回退期间业务如何继续。回退窗口内源系统保持可读可写状态，窗口结束后再关闭源系统。回退机制的具体细节属于实施约定事项，应在迁移方案中与实施方书面确认，不能默认存在。
切换后设置观察期，安排问题响应人和响应时限，收集业务侧反馈并逐条登记处理。观察期内发现的问题按严重程度分流：影响业务开展的问题立即评估是否触发回退；字段显示、权限微调等一般问题在观察期内修正并记录。观察期结束后，由业务负责人确认迁移完成，核验报告、批次记录和问题处理记录一并归档。
常见问题
源系统导出权限不足或导出内容不含历史记录，迁移还能按计划推进吗？
可以推进，但需要先调整计划。导出权限不足时，先申请权限并做一次小规模导出验证，确认能导出工作项、附件、评论和用户信息；导出内容不含历史记录时，要在范围清单中把“历史记录”标注为受限项，并决定是接受缺失、从其他来源补充，还是调整目标侧的呈现方式。
这类限制会影响核验标准：数量核验仍可按条数比对，评论与历史核验则要改为“可迁移部分一致，缺失部分有登记”。限制项应写入迁移方案，由业务负责人确认后再进入试迁移。
目标系统的字段和状态还没建好，可以先开始试迁移吗？
不建议。字段映射表需要目标字段作为对齐对象，目标侧字段类型、必填规则和状态集未确定时，映射表只能停留在草稿状态，试迁移结果也无法作为正式迁移的依据。
可行的做法是先完成目标系统的最小骨架：项目、字段定义、状态集、用户与用户组。骨架建好后立即冻结一轮，作为映射和试迁移的基准；后续如需调整字段，走变更记录并同步更新映射表，避免试迁移与正式迁移使用两套规则。
枚举值在目标侧找不到对应项时，默认值怎么定才不会在核验时产生争议？
默认值的选择要同时满足两个条件：业务上可接受，且原值可追溯。常见做法是映射到语义最接近的目标值，同时在备注字段保留原值，并在映射表中写明该规则和需要人工确认的范围。
核验时按映射表判断，而不是按个人理解判断。业务负责人对默认值映射逐条确认后签字，确认记录与映射表一并归档；后续发现某类默认值不合适，按变更流程修正映射表并重迁受影响批次，不在核验现场临时改口径。
分批迁移时，某一批核验不通过，是整批重迁还是只补差异数据？
取决于问题类型。数量差异通常要先排查导出与入库环节，确认是导出缺失、入库失败还是重复导入，再决定整批重迁或补导差异；字段值偏差一般回到映射表修正规则后重迁受影响批次，因为同一规则影响的范围往往大于已发现的记录；附件缺失先检查存储与大小限制，补齐后可只补传缺失附件。
无论哪种处理，都要在批次记录中注明问题、修正内容和重迁范围，保证后续批次和正式迁移不重复同一问题。
回退窗口内源系统应该保持什么状态，窗口结束后如何关闭？
回退窗口内源系统保持可读可写，业务在目标系统遇到阻塞时可以回到源系统继续处理；窗口结束后再关闭源系统的写入。窗口时长根据观察期的问题处理速度和增量回补能力确定，并在切换计划中写明起止时间。
回退方式、责任人和窗口时长属于实施约定事项，应在迁移方案中与实施方书面确认。触发回退后，需要把窗口期内源系统新增的数据纳入下一次迁移的增量范围，避免两边数据分叉。
