研发数据增量迁移可以拆成“全量基线＋增量追平”两段：先做一次带时间戳的全量快照作为基线，再按来源系统的更新时间、版本号或变更日志抓取基线之后的变更，按实体依赖顺序回放，最后用数量、字段值、附件与链接抽检确认追平。本文按范围界定、开工输入、抓取映射回放、核验留证、暂停回退五个阶段展开，讨论对象限于数据内容，流程配置与插件行为迁移、最终验收与切换结论不在本文范围。
要点总览（TL;DR）
- 把迁移拆成“全量基线＋增量追平”：先做带时间戳的全量快照，再抓取基线之后的变更，按实体依赖顺序回放。
- 增量抓取要固定可重复口径：按更新时间窗口或游标记录每轮起止位置，相邻窗口保留重叠量并用对象标识去重，降低边界漏数。
- 字段映射先比对取值域与语义再决定直接映射、值转换或补充映射表；用户身份按账号或邮箱匹配，匹配不上的进入待确认队列。
- 追平后按对象比对新增与变更数量，抽样核对关键字段、状态、负责人，并抽检附件可下载、关联可跳转，核验记录归档。
- 预设暂停与回退条件：映射错误率或失败条数超阈值、来源系统发生结构性变更时暂停，回退到基线重放需基线可恢复、目标可清理、日志可追溯。
增量迁移的源、目标与对象范围怎么定
增量迁移的第一步是把方向钉死：数据从来源系统流向目标系统，来源系统在迁移期间仍是研发团队的实际作业系统，目标系统处于承接和追平状态。方向一旦颠倒，后续的抓取口径、映射表和核验基准都会失去参照。范围表要写清每个对象从哪来、到哪去、以什么时间点切分，避免执行中反复确认。
纳入增量的实体通常包括工作项、需求、缺陷、迭代、评论、附件和关联关系。这几类对象的变更频率和依赖关系不同，建议在范围表中分行列出，而不是笼统写“研发数据”。基线时点取全量快照完成的时刻，增量起始时间与基线时点对齐，允许少量重叠，但要在表中注明重叠窗口，防止边界时刻的数据被两边都跳过。
| 对象 | 来源 | 目标 | 时间边界 | 负责人 |
|---|---|---|---|---|
| 工作项（需求、任务、缺陷） | 来源系统项目 | 目标系统对应项目 | 基线时点之后 | 迁移执行人 |
| 迭代 | 来源系统迭代 | 目标系统迭代 | 基线时点之后 | 迁移执行人 |
| 评论 | 来源系统工作项评论 | 目标系统工作项评论 | 基线时点之后 | 迁移执行人 |
| 附件 | 来源系统附件库 | 目标系统附件 | 基线时点之后 | 迁移执行人 |
| 关联关系 | 来源系统链接关系 | 目标系统关联 | 基线时点之后 | 迁移执行人 |
范围表还要写明不纳入本文的对象：流程配置、插件行为、迁移结果的最终验收结论与切换决策。把这些内容排除在外，是为了让增量阶段只对数据内容负责，避免执行人把配置迁移和验收判断混进同一轮工作。
增量迁移前需要准备哪些输入和依赖
增量迁移能否开工，取决于几项输入是否齐备。建议把下面这份清单作为开工门槛，逐项打勾后再启动第一轮增量，缺项时先补齐而不是带着缺口试跑。
- 全量基线快照及完成时间。快照要可回退，完成时间精确到分钟，作为增量抓取的起点依据。
- 来源系统的变更识别依据。确认来源系统提供更新时间字段、版本号或变更日志中的哪一种，并验证该字段在批量修改、状态流转、评论新增等场景下都会更新。若只有更新时间字段，要确认其精度是否满足窗口切分。
- 用户身份与字段映射表初版。列出来源与目标的账号、邮箱、姓名字段，以及关键业务字段的对应关系，标注需要转换的字段。
- 目标系统的承接结构。项目、工作项类型、字段结构、状态值已建好，字段类型与取值域与映射表一致。
- 增量窗口的调度方式与执行账号权限。明确每轮增量的执行时间、窗口长度、执行账号对来源读取和目标写入的权限范围，以及失败重试由谁触发。
这份清单同时是依赖检查表：基线未完成不能开增量，变更识别依据未验证不能定窗口，映射表未定稿不能批量回放。把检查结果记录在案，后续出现追平差异时可以回溯是哪项输入发生了变化。
增量数据怎么抓取、映射和回放
增量执行的核心是固定一个可重复的抓取口径。按更新时间窗口抓取时，每轮记录起点和终点，并在相邻窗口之间保留一段重叠量，例如上一轮终点回退若干分钟作为下一轮起点，用对象标识去重，降低边界时刻漏数的风险。按游标或变更日志抓取时，记录每轮消费到的游标位置，失败重试从上次成功位置继续。两种口径都要求每轮输出起止时间、处理条数、失败条数，形成可对照的执行日志。
字段映射不能只看字段名。同名字段在来源和目标中含义不同是常见情况，例如“状态”在来源系统可能包含自定义流转值，在目标系统中对应另一套状态集合；“优先级”的取值档位也可能不一致。处理顺序是先比对取值域与语义，再决定直接映射、值转换，还是补充一张映射表把来源值逐项对应到目标值。无法对应的值进入待确认队列，不默认落到某个兜底值。
| 来源字段 | 目标字段 | 语义比对结论 | 处理方式 | 备注 |
|---|---|---|---|---|
| 状态 | 工作项状态 | 取值集合不同 | 值转换表 | 逐项列出对应关系 |
| 优先级 | 优先级 | 档位数量不同 | 值转换表 | 合并档位需业务确认 |
| 负责人 | 负责人 | 账号体系不同 | 身份匹配 | 按账号或邮箱匹配 |
| 自定义字段 | 扩展字段 | 类型可能不同 | 直接映射或转换 | 类型不一致时先转换 |
用户身份按账号或邮箱匹配，匹配不上的进入待确认队列，由业务负责人确认对应关系后再回放，避免把变更记到错误的人名下。回放顺序遵循父项先于子项、实体先于关联关系：先回放迭代和工作项主体，再回放评论与附件，最后回放关联关系，保证引用目标已经存在。
同一对象在一轮或多轮增量中可能被多次变更，需要事先约定合并与覆盖规则：以来源系统的最新值为准覆盖目标值，历史变更通过执行日志留痕；字段级冲突时以来源为准，并在日志中记录冲突字段、来源值和目标原值。规则写进执行文档，避免每轮回放时临时判断。
在目标系统承接工作项、字段与附件的场景中，ONES 的迁移方案覆盖项目、工作项、状态、字段、附件和历史记录等内容，Jira 问题数据迁移包括属性和属性值、附件、评论等信息，可作为映射表设计和回放后核对的参照；具体增量同步机制与限制需在方案评估时向厂商确认。
增量追平后怎么核验与留证
追平判断不能只看“跑完了”，要按对象比对基线之后的新增与变更数量。做法是以来源系统同一时间窗口内的变更记录为基准，与目标系统实际写入条数逐对象对照，差异要能解释：属于待确认队列的、属于失败重试的、属于规则排除的，分别计数。
- 数量核验。按工作项、迭代、评论、附件、关联关系分别比对新增与变更条数，记录差异及原因。
- 字段抽检。抽取一定比例的工作项，比对关键字段值、状态和负责人，重点覆盖发生过状态流转和负责人变更的记录。
- 附件与链接抽检。确认附件可下载、可打开，关联关系可跳转到正确目标，评论挂载在工作项下。
- 执行记录。每轮增量记录起止时间、处理条数、失败条数与重试结果，失败项要跟踪到关闭。
| 核验项 | 核验方法 | 结果 | 差异说明 | 核验人 |
|---|---|---|---|---|
| 新增与变更数量 | 按对象对照来源变更记录 | 一致／有差异 | 记录差异条数与原因 | 迁移执行人 |
| 关键字段值 | 抽样比对 | 通过／不通过 | 列出不一致字段 | 迁移执行人 |
| 附件可下载 | 抽检打开 | 通过／不通过 | 记录失败附件 | 迁移执行人 |
| 关联可跳转 | 抽检点击 | 通过／不通过 | 记录断链对象 | 迁移执行人 |
核验记录归档保存，作为后续切换判断的输入。归档内容包括范围表、映射表、每轮执行日志和核验记录表，按轮次编号，便于在出现争议时定位到具体窗口和具体对象。
增量迁移中的回退与停止条件
增量阶段需要预设暂停和回退的触发条件，把判断标准写在执行文档里，而不是等出现问题再临时决定。常见触发条件包括：字段映射错误率或失败条数超过预设阈值；来源系统在增量期间发生结构性变更，例如字段被删除、状态集合调整、项目结构调整，导致既有映射失效；目标系统写入出现大面积失败或重复写入。
触发暂停后，先停止新一轮抓取，保留已写入数据和执行日志，定位问题来源。若问题出在映射规则，修正映射表后从暂停窗口的起点重放；若问题出在来源结构变更，需要重新比对字段语义并更新映射表，再决定是否回退。回退到全量基线并重放增量的前提是：基线快照仍可恢复、目标系统可清理基线之后的写入、增量执行日志完整可追溯。三个条件缺一，回退本身会带来新的不一致。
切换前若增量追平与核验未通过，应停止推进切换，把未通过项列入待办并明确责任人和完成时间。停止条件的作用是保护数据一致性，让迁移在可控范围内推进，而不是在差异未解释清楚的情况下进入下一阶段。
常见问题
增量窗口的重叠量设多大合适，怎么避免重复写入？
重叠量取决于来源系统更新时间字段的精度和批量操作的时间跨度。如果字段精度到分钟，重叠量至少覆盖一次批量修改可能跨越的时间；如果来源系统存在延迟写入，重叠量还要留出余量。重复写入通过对象标识去重解决：每轮回放前先按工作项编号、评论编号等唯一标识判断目标系统中是否已存在，存在则按合并覆盖规则更新，不存在则新建。重叠量、去重字段和覆盖规则应写进执行文档，每轮保持一致。
来源系统只提供更新时间字段，没有变更日志，还能做增量吗？
可以按更新时间窗口抓取，但需要先验证该字段的更新覆盖范围：批量修改、状态流转、评论新增、附件上传等场景是否都会刷新这个字段。如果某些变更不刷新更新时间，窗口抓取会漏掉这部分数据，此时应把这些对象单独列出，改用其他识别依据或按全量重扫处理。字段精度不足、无法切分窗口时，可以放大窗口并延长重叠量，同时增加数量核验的频次。
用户身份匹配不上时，能不能先挂到默认账号，后续再改？
不建议默认挂到某个账号。变更记录一旦落到错误的人名下，后续修正需要逐条追溯，工作量远大于在增量阶段处理待确认队列。更稳妥的做法是让匹配不上的记录进入待确认队列，由业务负责人确认账号对应关系后再回放；如果确认周期较长，可以先回放不依赖该身份的数据，把涉及该身份的记录单独成批，在核验记录中标注未完成项。
增量追平后，切换前还需要再跑一轮增量吗？
通常需要。追平核验通过只说明截至该轮窗口终点数据一致，来源系统在核验期间仍在产生新变更。切换前应再执行一轮增量，把核验期间的新增与变更追平，并对这一轮做同样的数量与抽检核验。切换窗口内建议暂停来源系统的写入或明确冻结时间点，让最后一轮增量的终点与切换起点对齐，减少切换瞬间的差异。
回退到全量基线重放增量，代价大不大，什么情况下值得做？
回退重放的代价取决于基线之后积累的变更量和目标系统已写入数据的清理难度。适合回退的情况是映射规则整体性错误、来源系统结构变更导致大范围映射失效，或目标系统出现大面积重复写入，此时逐条修正的成本高于重放。如果只是少量记录失败，优先在增量层面重试和补录，保留已有写入结果。决定回退前先确认三个前提：基线快照可恢复、目标系统可清理基线之后的写入、增量执行日志完整可追溯。
