货代系统上线前，不要把全部旧数据一次性导入。应先划定迁移范围与可信来源，统一字段口径，再用脱敏样本验证关联、权限和查询结果，最后处理在库、在途及未结业务。
迁移验收不能只看“文件导入成功”。真正要确认的是客户、订单、货物、费用和权限在新系统中仍能正确关联，并且每类数据都有负责人确认。
第一步：先决定哪些数据要迁移
“全部迁移”看似稳妥，实际上可能把重复记录、失效账号和旧口径一起带进新系统。可先按业务连续性划分范围，再决定迁移、清理或只读保留。
| 数据范围 | 常见内容 | 处理建议 | 确认角色 |
|---|---|---|---|
| 当前主数据 | 客户、供应商、联系人、服务及费用项目 | 去重并统一名称、状态和停用规则后迁移 | 业务与财务负责人 |
| 当前业务数据 | 在库货物、在途订单、待处理异常 | 作为切换重点，逐项核对对象关联和状态 | 业务、操作与仓库 |
| 未结财务数据 | 应收、应付、待确认费用和币种信息 | 明确归属与确认状态，不混入已结数据 | 财务负责人 |
| 用户与权限 | 用户、岗位、角色和可见范围 | 按现岗位重新确认，不照搬失效账号 | 管理员与部门负责人 |
| 历史已结数据 | 已完成订单、过期报价和旧联系人 | 结合留存、查询需求和质量决定迁移或只读归档 | 业务、财务与管理角色 |
第二步：字段映射不是简单改列名
每个关键字段至少要说明业务含义、可信来源、目标位置、转换规则、是否必填和确认人。下面的映射轨道可直接用于讨论：
客户名称与别名→客户主档核对重复判断、标准名称和别名保留方式
订单号与子单号→主订单及关联记录核对唯一性、父子关系和历史编号
数量与单位→货物明细保留原始单位，确认标准单位与换算规则
费用项目与币种→订单费用核对应收应付归属、币种和确认状态
用户与岗位→角色权限确认可见范围、可操作动作和失效账号
如果映射规则有误，不要只在目标数据里逐条手工改数。应先修正规则，再重新导入样本，否则正式迁移时同类问题仍会批量出现。
第三步：用脱敏样本验证边界情况
样本不应只选字段完整、流程顺畅的标准订单，还要覆盖重复客户、状态变更、异常货物、费用待确认、不同币种和权限差异。至少回答四个问题：
字段是否正确？名称、数量、单位、状态和费用没有错位或截断。
金额与状态能否解释？原始币种、确认状态和调整记录没有被静默覆盖。
对象关联是否保留？客户、主订单、货物、费用、附件和异常仍能互相追溯。
权限是否符合岗位？不同岗位只能查看和操作已经确认的范围。
第四步：切换前逐项确认
- 最终迁移、排除和只读归档范围已经确定。
- 每类数据都有唯一可信来源与业务负责人。
- 重复客户、失效联系人和无效账号有处理规则。
- 在库、在途、未结费用和异常已完成切换前复核。
- 映射与转换规则保留版本，异常处理方式可追溯。
- 样本已经验证字段、关联、权限和查询结果。
- 切换期间的新数据入口与负责人员已经明确。
- 问题记录、回退条件和旧数据查询方式已经确定。
系统迁移能否只交给技术人员？
不能只由技术人员决定业务口径。技术人员可以处理导出、转换、导入和错误记录，但客户合并、状态含义、费用归属、库存可信来源和岗位权限，需要业务、仓库、财务及管理角色共同确认。
系统供应方可以协助评估字段、导入方式和实施范围，但具体可迁移内容、接口能力、部署方式和切换计划，应以产品资料、实际演示及书面项目范围为准。准备数据前，也可先参考主订单与跨部门数据治理方法。
常见问题
历史订单是否必须全部迁移？
不一定。已结业务可结合留存要求、查询频率和数据质量选择迁移或只读归档；当前在库、在途和未结业务更需要优先保证连续处理。
数据导入成功，是否等于迁移完成？
不等于。还要验证字段含义、金额与状态、对象关联、角色权限和实际查询结果，并记录异常数据的处理方式。
