系统迁移失败往往不是数据没有导进去，而是导入后无法证明与原系统一致。客户重复、商品单位错误、库存总数相同但仓库分布不同、应收余额缺少明细，都可能在上线后变成业务中断和对账争议。

迁移前先确定范围和基准时间。哪些主数据迁移、哪些未完成单据继续执行、哪些历史数据只保留查询、库存和往来以哪个时点为准，都应形成清单。没有范围边界时，团队会在临近切换时不断增加数据，核对标准也随之变化。

第一轮是结构核对，重点检查字段映射和数据可导入性。客户、供应商、商品、单位、仓库、部门和人员分别对应新系统什么字段，必填值如何补齐，旧编码是否保留，停用资料如何标记。此轮不追求一次正确，而是尽早发现结构冲突。

第二轮是业务核对，选取能够贯穿流程的样本。用迁移后的客户和商品创建订单，检查价格、单位、库存和权限；抽取部分应收应付追溯到原单；按仓库、商品和批次比较库存。业务人员需要参与，因为只有他们知道哪些异常是历史事实，哪些是脏数据。

第三轮是切换核对，在约定的冻结窗口内提取最终增量。先确认旧系统停止新增或采用明确的增量规则，再导入最新客户、未完单据、库存和往来。导入后同时比较总额、分类汇总和关键明细，不能只看一个总数相同就宣布完成。

核对记录应保留双方口径。每一类数据写清旧系统查询条件、新系统查询条件、记录数、金额或数量、差异项和处理结果。对于确实无法修复的历史问题，应由业务负责人确认如何带入，而不是由实施人员直接删除或改成看似平衡的数字。

正式切换还需要回退方案。明确什么条件下暂停启用、谁决定回退、旧系统能否恢复录入、切换期间产生的线下单据如何补录。回退并不代表项目失败，而是为关键数据和连续经营预留安全边界。

切换后的观察期也要提前安排。每天核对新增订单、库存负数、往来差异、接口失败和用户反馈，将问题分为数据、配置、流程与培训四类。修复数据时使用可审计的调整单或迁移补丁，记录原因和审批人，不允许团队绕过系统直接改数据库来追求表面一致。

每一类迁移数据都应有业务负责人。技术团队负责转换和工具，客户、商品、库存与往来负责人分别确认口径和差异。责任写进迁移清单，能避免所有问题集中到上线当天，也防止技术人员替业务部门决定哪些历史记录可以舍弃。

迁移验收应关注可用、可核对和可追溯。三轮核对分别解决字段能否承载、业务能否运行和最终余额是否一致，再配合冻结、差异签字与回退方案，才能让新系统从第一天起建立可信的数据起点。

下一步建议

将本文提到的判断标准放入一条真实业务流程中验证，并在方案中明确角色、数据口径、异常处理和验收样例。