旧系统数据迁移怎么做？盘点、清洗、试迁移、对账与回滚

直接答案：先确定哪些数据必须进入新系统，再定义字段映射和清洗规则；至少完成样本试迁移、全量演练和切换前增量演练三轮，按记录数、业务状态、金额、库存和关联关系核对；正式切换前约定冻结时间、验收人、失败阈值和回滚后的数据处理办法。只要其中一项没有负责人或证据，迁移就还没有准备好。

数据迁移不是把 CSV 导入新后台。旧系统里的客户、订单、库存、付款、附件和审批记录通常依赖不同的编码、状态和时间口径。导入工具显示“完成”，不代表业务能继续；真正的完成标准是新旧数据可以解释、关键流程能接续、差异有清单、出问题能恢复。

一、先划迁移范围，不要默认搬走所有历史数据

按使用目的把数据分为四类，并给每类指定去向：

• 仍在处理中的业务，例如未完成订单、未结工单、在途采购、未核销款项和当前库存。通常需要进入新系统，且要能从原编号追溯来源。
• 继续使用的主数据，例如客户、产品、供应商、仓库、员工和组织。先确认谁是主责人、编码是否唯一，以及停用记录是否仍被未结业务引用。
• 需要查询但不再编辑的历史数据。可以迁入只读归档区，也可以保留在受控的旧系统或文件库，不一定要塞入新系统的可写业务表。
• 明确不迁移的数据，例如重复测试记录、已批准删除的临时资料或超出约定范围的内容。排除必须有规则、负责人和记录，不能在导入时临时决定。

迁移清单至少按数据对象记录：来源系统和表、时间范围、预计记录量、目标位置、是否包含附件、业务负责人、迁移方式、保留期限和验收证据。合同或项目范围也应说明哪些对象不在本次迁移中，避免“所有历史数据”变成无法估算的承诺。需求阶段如何把数据对象和一期范围先写清，可参考软件定制开发需求分析清单。

二、建立字段映射，先解释业务含义再转换格式

不要只把旧字段名改成新字段名。映射表应记录来源字段、目标字段、转换规则、必填与唯一约束、异常处理和复核责任。下面的内容可以复制为项目映射表，再按实际系统补充字段、状态和责任人：

状态名称相同不代表含义相同，单位、币种和时区也不能靠字段类型推断。转换规则要在试迁移前由业务负责人确认，不能等导入结果出现差异后再补定义。

如果旧系统的内部 ID 在新系统里没有意义，保留 source_system、source_id 和 migration_batch 等来源标识，后续客服、审计和补迁才找得到原记录。多套系统的主数据和接口归属也要一起梳理，可参考ERP 对接中的数据主责与验收方法。

三、先做数据剖析，再决定清洗规则

正式迁移前，对每个数据对象做一次剖析：总记录数、关键字段空值比例、重复业务键、非法编码、状态分布、日期范围、孤儿关联和附件缺失。剖析结果要带上查询时间、筛选条件和来源快照，否则同一张报表在不同日期跑出不同数字，双方很难判断差异来自哪里。

清洗规则要区分格式修正和业务判断。去掉多余空格、统一日期格式可以按确认过的规则批量处理；合并两个疑似重复客户、判断一笔付款属于哪张订单、推断已经失效的审批结果，则必须交给业务负责人确认。不要静默覆盖原值；保留原始值、清洗后值、规则版本、处理结果和异常原因，确保修改可回查。

测试数据优先使用脱敏副本。临时导出文件、数据库快照和传输账号要限制访问，迁移日志只记录定位问题所需的编号和状态，不要写入密码、支付凭证或不必要的个人信息。

四、至少安排三轮迁移演练

第一轮是小样本验证。每种数据对象选正常记录、边界记录和已知异常记录，重点验证字段含义、状态转换、关联、编码和失败提示。样本要覆盖空值、重复、撤销、部分完成和跨月等真实边界，不要只挑最整齐的几行。

第二轮是全量演练。在与生产数据结构和规模接近的副本上跑完整迁移，记录开始和结束时间、处理速度、失败数量、重试结果、资源占用和人工核对时长。若某个对象需要手工修复，写明每批工作量和负责人，再据此安排正式窗口。

第三轮是切换前增量演练。确定冻结点后，只迁移最后一段新增或变更的数据，验证增量判定、重复执行和中断恢复。迁移任务应有批次号、检查点、错误记录和可安全重跑的幂等机制；某行失败时能定位并重试该行，不能为了重跑一小批而把已成功数据重复创建。

每轮都要留档：脚本或工具版本、输入快照标识、规则版本、输出批次、异常清单、对账结果和业务签字。人工复制粘贴可以用于少量特例的确认，不应成为不可复现的正式迁移流程。

五、用多种口径对账，不能只看导入成功率

先按来源对象、日期范围、组织、状态和业务类型拆分，再比较来源、成功、排除和失败数量。比如某个订单范围有 12,480 条来源记录，12,456 条成功导入，20 条按双方确认的规则排除，4 条待修复，则应满足：

来源记录数 = 成功导入数 + 已批准排除数 + 待修复失败数

这个例子只是核对方法的演示，不是可直接照用的业务阈值。每条排除和失败记录都要有唯一编号、原因、责任人和最终处理状态；如果几个数字无法解释到具体记录，迁移批次就不应验收。

数量之外，还要检查关键业务关系：订单是否关联到正确客户，退款是否关联到原付款，发票是否关联到正确订单，附件是否仍能打开，未结工单是否能继续推进。采用分层抽样，并对大额、零金额、部分完成、被撤销和跨组织等高风险边界定向抽查；记录抽样范围、选择方法、核对结果和复核人。

金额按相同币种、相同期间、相同业务状态对账，并分别检查订单额、已收款、退款和未结金额，避免用一个总数掩盖分类错误。库存按产品、仓库、批次和单位核对；若迁移范围包含完整流水，可按同一口径检查“期末 = 期初 + 入库 + 调入 + 生产退料 + 盘点增加 - 出库 - 调出 - 生产领料 - 报废 - 盘点减少”。只把实际纳入范围的流水类型放入公式，并解释单位换算和期初时点。

六、把正式切换写成可执行的时间表

切换方案应明确时间点、操作者、业务确认人、系统负责人、停止条件和下一步动作。下表可直接复制到项目运行手册；具体时间点和通过条件应按业务窗口填写：

迁移失败行要可定位、可重试，成功记录重复运行不会重复创建。

除非已经设计冲突解决和对账机制，不要让新旧系统同时接受同一业务的写入。双写会造成两边都成功、只有一边成功或同一操作执行两次，回滚时还要判断哪份数据才是最终事实。

七、先约定回滚条件，再安排上线窗口

回滚条件应按业务影响书面确认，而不是出问题后临时争论。常见停止或回滚触发点包括：关键业务记录缺失且无法在窗口内修复；金额或库存差异超过事先约定的容忍范围；用户权限出现越权；核心流程或外部接口连续不可用；备份无法恢复；迁移任务不能准确说明成功、排除和失败的数量。小的显示问题和阻断业务的完整性问题应区分处理。

回滚方案至少回答：谁有权做决定、最迟何时决定、如何恢复旧系统、切换后已在新系统产生的订单或审批怎样保留、哪些数据需要补写回旧系统、谁负责复核，以及用户如何收到通知。只把网站地址切回旧版并不等于数据回滚；如果切换后已经有新的业务写入，必须先捕获并核对这些变更，避免恢复旧系统时丢失。

演练时要真的验证恢复链路，而不是只确认“有备份文件”。检查备份的时间点、完整性、账号权限、恢复耗时和抽样数据；迁移脚本需要支持停止、续跑和重复执行，并能区分已经成功的记录。具体恢复目标和差异容忍度由业务风险、合同范围和技术能力共同确定，不存在适合所有项目的一组固定数字。

上线前可复用的验收清单

• 数据对象、时间范围和排除项均有业务负责人确认。
• 字段映射、状态转换、单位、币种和时区规则有版本记录。
• 重复、空值、孤儿关联和附件缺失都有处理规则。
• 样本迁移、全量演练和最终增量演练均留有结果。
• 来源记录数能够拆解为成功、批准排除和失败待处理。
• 金额、库存、关键关系和权限完成分组核对与抽样。
• 失败记录可定位、可重试，成功记录重复运行不会重复创建。
• 备份已验证可恢复，切换负责人、停止条件和回滚决定人明确。
• 切换后的新业务写入有捕获和核对办法。
• 旧系统何时只读、保留多久、如何导出和最终如何处置已确认。

这份清单可以作为项目验收附件的一部分，并与软件定制开发交付物清单中的阶段产物一起核对。

常见问题

旧系统的全部历史数据都要迁移吗？

不一定。正在处理的记录、持续使用的主数据通常优先迁移；已结单的历史记录可以按查询和审计要求只读归档。每类数据要说明保留目的、访问人和目标位置，不要把“全量迁移”当作默认方案。

Excel 数据可以直接导入新系统吗？

可以，但先核对列名、编码、日期格式、单位、必填字段、重复行和关联键。用脱敏副本做小样本导入，失败行要能下载或定位，并说明修复后如何重试。源表里写着“已完成”并不代表新系统知道它满足什么完成条件。

数据迁移需要多长时间？

不能只按文件大小估算。数据质量、对象关联、附件数量、接口能力、停机窗口、清洗责任和验收速度都会影响工期。先做剖析和全量演练，再给出处理速度、人工核对量和风险缓冲的估算。

旧系统可以提前停掉吗？

只有在业务确认新系统已接续未结事项、必要历史可查询、备份可恢复、账号和导出责任明确后，才适合停用。切换后通常先设只读并保留一段经确认的观察期，再按数据保留和合同要求处理旧环境。

怎样证明迁移已经完成？

需要一份可复核的迁移报告：范围与快照、脚本和规则版本、数量与金额对账、抽样结果、排除和失败清单、异常处理记录、恢复演练结论以及业务负责人确认。单独一张“导入成功”截图不足以证明数据能用于经营。

数据迁移的目标不是把旧系统的每个问题原样搬到新系统，而是让业务在切换后继续运转，并能解释每一条重要记录从哪里来、发生过什么、出了差异由谁处理。先把范围、映射、对账和回滚证据做实，再安排正式切换，项目上线会更可控。