旧管理系统换新系统，历史数据迁移怎么核对才不丢业务关系

旧管理系统迁移历史数据，建议以一条完整业务链作为验收单位：不仅确认订单还在，还要确认明细属于它、客户没有串号、附件能打开、处理历史没有被新规则改写。采购软件开发服务时，应把迁移范围、旧新编号映射、差异处理和切换条件单独列出，不能用“数据库导入成功”代替历史业务验收。

先确定迁哪些对象，以及谁依赖谁

从一张真实但经授权处理的业务单据向外追查：客户、合同、订单、明细、收发记录、附件、审批记录分别存在哪里。按实际业务列关系，不要求每个项目都有这七类。区分继续办理的单据、只读历史和不迁移的归档数据，并记录排除依据、保管位置与查询办法。

映射表要解释变化，不能悄悄改写历史

新系统重新分配内部编号时，建议保留旧系统名称、旧主键和新主键的对应记录。多个旧系统可能使用同一个订单号，因此编号的作用范围也要记录。已停用客户、离职经办人不能简单换成当前同名对象；历史显示名与当前账号的访问权限应分开处理。

状态合并、单位换算、时区处理和空值补齐都应有明确规则。旧状态“部分完成”若在新系统没有对应值，应保留原值或经业务确认后映射，不能默认当作完成。附件另核对文件数量、内容及关联；文件名相同不代表同一文件。涉及数据库类型和运行环境差异时，另按部署适配清单验证，不把环境通过当成内容通过。

试迁移分三层核对，差异必须回到具体记录

先按组织、年份和业务状态核对记录数量及适用的金额、数量合计，再核对主从关系、孤立明细和重复映射，最后由业务人员打开代表性单据完成查询或继续办理。总额相同仍可能有两笔单据互相抵消的错配；金额核对还应固定币种、精度及舍入规则。

AWS DMS 校验文档说明该工具可以比较源端与目标端的对应行并报告差异，同时存在主键或唯一索引要求。行级工具结果可以作为证据之一；本文建议增加的业务关系和文件核查，需要另行设计，不能由工具的“已校验”状态推定完成。

每条差异建议记录源编号、目标编号、比较字段、旧值、新值、原因、处理人及复验结果。历史脏数据也要标明“原有问题”，不能在迁移时静默修正，更不能把未验证的记录计入通过数。

最后一次增量要有可追溯的截止点

试迁移完成后，旧系统仍可能新增、修改或撤销单据。正式切换前，应约定停止相关写入的时间或可验证的变更水位，补入截至该边界的增量，再执行关键核对。保存源快照、映射规则版本、迁移批次和校验报告，使同一结果可以复查。

这里只判断历史搬迁是否完整；新旧系统在试用期间谁能继续写入，是另一个运行规则。若新系统已接收新业务，回退前还要处理这部分新增记录，不能只把入口切回旧系统。切换演练需要明确暂停条件和负责人的实际操作步骤。

哪些差异应阻止签收，历史问题怎样留档

• 关键单据缺失、重复或串联错误，尚未定位原因。
• 迁移批次包含未校验数据，却没有单独列出范围。
• 附件打不开、关联错误，或普通用户获得了不应有的历史资料权限。
• 最后增量没有明确边界，无法解释切换前后新增或撤销的记录。

以上是建议的阻断项，具体由业务负责人按影响确认。对暂不修复的原有缺陷，应留下可查询的差异清单和处理安排。若旧记录因规则变化只能只读，要明确是否仍需更正、补附件或关联新单，并为这些后续动作保留原记录引用。映射、脚本和复验材料应进入源码与项目交接清单，使接手人员能解释一笔历史业务从哪里来。