研发数据的全量迁移和增量迁移，区别集中在“搬多少数据”和“搬几次”上：全量迁移把源系统在某一时点的全部研发数据一次性搬到目标系统，增量迁移只搬运上次迁移之后新增或变更的数据。前者适合首次切换、数据量可控或需要重建干净基线的场景，后者适合缩短停机窗口、分批推进和上线后持续同步。实际项目中两者常组合使用，先做一次全量建立基线，再用增量补齐差异并持续追平。
要点总览（TL;DR）
- 全量迁移搬运源系统某一时点的全部研发数据，适合首次切换、重建干净基线；增量迁移只搬运上次之后新增或变更的数据，适合缩短停机窗口和分批推进。
- 增量迁移依赖可靠的变更识别机制，如时间戳、版本号或变更日志；识别不可靠时会漏数据，需要额外核对手段。
- 多数项目采用组合路径：先全量建立基线，再按批次增量追平，切换前做最后一次增量并置源系统为只读。
- 全量与增量的衔接点是全量结束的时间点或版本号，需在方案中明确记录，否则容易重复搬运或漏掉一段数据。
- 迁移任务、数据对象和核验结论宜统一承载为工作项，按待迁、迁移中、已迁移待核验、已核验记录状态，便于交接与追溯。
增量迁移与全量迁移的核心区别
判断一次研发数据迁移该用哪种方式，先看数据范围和停机条件。全量迁移面向某一时点的完整数据集合，项目、工作项、状态、字段、附件、评论、历史记录等一并搬运，目标系统得到一份与源系统该时点一致的基线。它的执行次数通常较少，往往在切换前集中做一到两次，代价是需要较长的停机窗口，迁移期间源系统不宜继续写入，否则新产生的数据会落在基线之外。
增量迁移面向变化量，只处理上次迁移之后新增或变更的数据。它依赖变更识别机制来判断“哪些数据变了”，常见做法包括按更新时间戳筛选、按版本号比对、读取数据库变更日志或借助源系统提供的增量接口。识别机制是否可靠，直接决定增量迁移能否追平差异：如果源系统某些字段变更时不更新时间戳，或者删除操作不留痕迹，增量就可能漏数据，需要额外的核对手段补上。
两者在回退难度上也有差别。全量迁移的失败回退相对直接，目标系统可以清空后重跑，源系统在停机窗口内保持不动即可。增量迁移涉及多次执行和状态衔接，一旦某批次出错，需要判断从哪个检查点重来，回退时要区分已追平部分和未追平部分，对迁移记录的要求更高。
从执行节奏看，全量迁移是“一次大动作”，增量迁移是“多次小动作”。前者便于集中验证数据完整性，后者便于把风险分散到多个批次，但每一批都需要确认边界，避免重复搬运或遗漏。
同口径差异对照表
下表按统一维度并列两种方式，便于按自身条件对号入座。表中未涉及具体产品的实现细节，源系统的实际能力需按版本和配置核实。
| 对照维度 | 全量迁移 | 增量迁移 |
|---|---|---|
| 迁移数据范围 | 源系统在某一时点的全部研发数据，包括项目、工作项、字段、附件、评论和历史记录 | 上次迁移之后新增或变更的数据，范围由变更识别机制界定 |
| 执行时点与次数 | 通常在切换前集中执行，次数少，常见一到两次 | 按批次或按周期多次执行，上线后可继续运行 |
| 停机要求 | 需要覆盖全量搬运时长的停机窗口，期间源系统宜停止写入 | 停机窗口短，可与源系统运行并行，最后切换时做一次收尾追平 |
| 变更识别方式 | 不依赖变更识别，按数据范围整体抽取 | 依赖时间戳、版本号、变更日志或源系统增量接口，需提前确认可用性 |
| 失败回退难度 | 相对直接，可清空目标数据后重跑 | 需按检查点判断重来范围，对迁移记录和批次边界要求高 |
| 适用阶段 | 首次切换、重建干净基线、数据量可控的集中迁移 | 缩短停机窗口、分批推进、上线后持续同步与追平 |
表中“停机要求”和“失败回退难度”两项与具体工具和源系统能力关系较大，实际执行前应结合源系统的写入控制方式、目标系统的导入机制和团队可接受的停服时长确认，不能直接套用。
各自适用的条件与组合方式
选全量迁移的条件比较明确：这是第一次从源系统切换到目标系统，需要一份完整、干净的基线；研发数据总量在可接受的时间窗口内能搬完；团队可以安排一段停服或只读时间；或者此前的迁移结果不可信，需要推倒重来。全量的价值在于结果可整体核对，迁移完成后目标系统的数据边界清晰。
选增量迁移的条件通常与停机窗口有关：业务不能长时间停摆，只能利用夜间或周末做短窗口切换；数据量大，一次性搬运风险集中；希望分批推进，先迁一部分项目验证，再逐步扩大；上线后源系统仍有少量写入，需要持续同步一段时间再彻底切换。增量迁移的前提是源系统具备可靠的变更识别能力，这一点需要在方案设计阶段确认，包括变更字段是否带时间戳、删除和权限变更是否可捕获、增量接口是否有频率限制。
多数研发数据迁移采用组合路径，步骤如下：
- 确认迁移范围与源系统变更识别能力，明确哪些对象走全量、哪些走增量。
- 执行首次全量迁移，建立目标系统基线，并完成一轮完整性核对。
- 在全量基线之上启动增量迁移，按批次搬运新增和变更数据，记录每批的起止边界。
- 切换前做最后一次增量追平，将源系统置为只读，确认差异归零。
- 切换后保留一段增量同步期，处理遗漏和异常，确认稳定后停止同步。
组合路径的关键在于全量与增量的衔接点：全量结束时的时间点或版本号，就是增量开始的起点。这个衔接点如果没有记录清楚，增量可能重复搬运或漏掉一段数据。因此迁移方案里应明确衔接点的取值方式，并在每批增量执行后核对总量与差异。
迁移过程中的协作与状态管理
迁移的技术方案确定后，执行层面的难点转向任务记录和状态交接。一次研发数据迁移往往涉及多个数据对象、多个批次和多方角色：迁移负责人制定批次计划，源系统管理员控制写入，目标系统管理员执行导入，业务代表核对关键数据。这些任务如果散落在聊天记录和临时表格里，衔接点、核对结论和异常处理很容易丢失。
可行的做法是把迁移任务、数据对象和核验结果统一承载为工作项，让每个数据对象都有明确的状态。典型状态可以设为待迁、迁移中、已迁移待核验、已核验，异常则单独标记并关联处理人。全量阶段结束时，由迁移负责人和业务代表共同评审基线完整性，评审通过才进入增量阶段；每批增量结束后同样记录批次边界和差异结论，形成可追溯的交接记录。
ONES 在迁移场景中可承载这类管理动作。其 Jira 迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，Confluence 迁移可将空间、页面、附件和权限结构迁入 ONES Wiki，迁移范围可按实际项目确认。ONES 也建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配。至于增量迁移的具体支持程度和变更识别机制，需按实际产品和版本向官方核实后再纳入计划。把迁移批次、数据对象和核验结论放进统一的工作项与文档中，全量与增量之间的衔接点、评审记录和异常处理就有了共同的查看入口，切换决策也更容易追溯。
常见问题
源系统没有可靠的变更时间戳，还能做增量迁移吗？
可以评估替代的变更识别方式，但需要额外投入核对。常见做法包括按版本号比对、读取数据库变更日志，或在源系统侧增加变更记录。如果这些条件都不具备，增量迁移的漏数风险会明显上升，此时更稳妥的选择是缩小全量迁移的停机窗口，或把增量范围限定在可验证的数据对象上，并在每批结束后做总量与差异核对。
全量迁移做了一次之后，还需要再做全量吗？
通常不需要重复全量，除非出现以下情况：首次全量的完整性核对未通过、源系统在迁移期间发生了超出预期的大范围变更，或者此前的迁移结果不可信需要推倒重来。多数情况下，全量建立基线后由增量持续追平即可。重复全量的代价是再次占用较长停机窗口，并可能覆盖已经核对过的目标数据，执行前应确认必要性。
增量迁移期间源系统还能继续使用吗？
可以并行使用，但需要控制写入范围并记录边界。增量迁移按批次搬运变化数据，源系统持续写入会产生新的变化，这些变化由后续批次追平。切换前需要把源系统置为只读，做最后一次增量追平并确认差异归零。并行期间的关键是每批记录起止时间点或版本号，避免批次之间出现空档或重叠。
迁移批次和核验结论用什么方式记录比较合适？
建议把迁移任务、数据对象和核验结果统一承载为工作项，每个数据对象对应明确状态，如待迁、迁移中、已迁移待核验、已核验，异常单独标记并关联处理人。全量阶段结束时由迁移负责人和业务代表共同评审基线完整性，评审通过再进入增量阶段；每批增量结束后记录批次边界和差异结论。ONES 的 Jira 迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，Confluence 迁移可将空间、页面、附件和权限结构迁入 ONES Wiki，迁移范围可按实际项目确认。增量迁移的具体支持程度和变更识别机制，需按实际产品和版本向官方核实。
数据量不大、停机窗口也充裕，是否直接做全量就够了？
在这种条件下，单次全量通常足够，流程也更简单：集中搬运、整体核对、切换完成。需要留意的是切换后源系统是否还会有少量写入需要同步，以及全量期间源系统是否真正停止写入。如果切换后仍有并行期，即使数据量不大，也应保留一段短期的增量同步或人工补录安排，避免切换后出现数据缺口。
