企智社 
半年前，我们接到一个老系统替换项目的前置任务：把一套运行了近十年的 ERP 系统里的数据，迁到客户新选型的平台上。按照很多人理解，这无非“导出、清洗、导入”。但作为长期做企业定制开发的服务方，我清楚这件事远没有那么简单。项目正式上线后，回望整个过程，真正难的不是技术，而是对老系统的理解、对风险的敬畏、对业务边界的判断。现在把这段复盘写下来，算是给自己和团队留个提醒。
先别急着写脚本，把老系统“当陌生人”重新摸一遍
第一次和客户开摸底会时，对方拿出的数据字典是十年前的版本，很多字段注释写的是“预留”“备用”“自定义文字”，实际早就变了味道。我们没有立刻写迁移脚本，而是先做了一件事：把老库备份恢复到测试环境，逐表查看字段注释、枚举值、计数和空值比例。结果比预想中更乱。
同一个客户主数据表里，一家供应商出现了三个名称变体：“华东机电”“华东机电有限公司”“HUADONG MACHINE”。库存表里有负库存，因为老系统允许先出库后补入库单。历史工单中的物料编码，有一些已经在最新物料主数据里被停用，但挂在半年前的订单上。最让人头疼的是，某个看起来像日期类型的字段，存储的其实是“备注”文本，因为早年没有用户备注栏，业务人员只能往旁边塞信息。
我们意识到，老系统不是一个“数据仓库”，而是一个被多年“打补丁”的活系统。为了把数据摸透，我们给客户提了一个要求：安排几位懂老业务的关键用户参与访谈，尤其是仓库、财务、销售这三个部门。事实证明，这一步比任何自动化分析都管用。仓库主管指着一列代码说：“这个状态字段，系统里只写了 A、B、C，但 B 其实代表两种意思，要看后面的时间。”财务主管补充：“某些凭证金额是红字冲销，老系统用负数表示，但导出后有的负号会丢失。”
为了不让摸查结果藏在个人脑子里，我们专门定制了一套“字段血缘整理模板”，把每个关键字段的原始定义、实际用法、异常样例、对应联系人记录下来。这个模板后来成了整个迁移项目最重要的依据。市面上虽然有通用的数据剖析工具，但面对这种充满人情味的老系统，真正好用的还是要针对客户现状做二次定制。我们把它当作一个起点：先承认自己对老数据不了解，才有可能真正了解它。
“全量迁移”和“按需迁移”的取舍，其实是个业务决策
第二个大问题，是迁什么。客户 IT 部门一开始强烈要求“全量迁”，说历史数据不能丢。但业务部门立刻反对：销售总监说三年前的报价单早就失效了，但客户可能会翻旧账，所以订单要保留；财务说总账和明细账必须完整，否则审计过不了；生产计划主管说去年的工艺参数不需要了，新设备新工艺已经换了三套。
这种分歧说明，迁移范围不能靠技术部门拍脑袋。我们组织了一次专题会，把数据分成三大类：基础数据、历史交易数据、配置数据。基础数据包括客户、供应商、物料、BOM、工艺路线，这些决定了新系统能不能开张，必须完整、干净。历史交易数据要区分“未完结合同”和“已关闭单据”：未完结订单、未交货销售单、未过账凭证，需要以可继续业务的状态迁入新系统；已关闭的历史单据，可以采用“留档查询”的方式，不进入核心交易逻辑。配置数据包括权限、审批流、打印模板，这些看起来不起眼，但丢一个都会让业务人员抓狂。
我们为每一类数据定制了一套迁移范围确认表，上面写清楚：哪些表、哪些年份、哪些状态、迁移方式是什么、不迁的话怎么处理。这份表拉出来，让每个部门负责人签字确认。表面上看多了一道流程，实际上是为了防止上线后有人回头问“为什么 2017 年的报价单查不到？”——有了签字记录，争议就能回到规则本身。
这里还有一个容易被忽视的坑：很多企业以为“全量迁入新系统”最安全，其实历史数据一旦进入新系统核心表，会影响性能、索引、审批流程，甚至造成权限混乱。适当“封存”历史数据，不是丢数据，而是给新系统减负。我们最终给客户设计了一个“冷热分离”方案：热数据进入新系统业务表，冷数据进入专门的历史数据查询库。这样做既满足了财务审计的完整性，又让日常操作速度不受干扰。
迁移中的风险控制：不是测试三轮就够
真正进入迁移执行阶段后，我们把风险控制拆成了四个环节：预迁移、模拟迁移、正式切换、上线后比对。预迁移主要验证数据抽取和转换规则，模拟迁移要在完整环境下跑通所有流程，正式切换才是动真格的。听起来很常规，但细节里全是雷。
第一个雷是编码映射。老系统的物料编码是 10 位，新系统是 20 位，而且编码规则完全不同。我们一开始想用“老编码 + 前缀”的方式自动生成，试跑后才发现很多老编码其实已经不唯一，有两条物料用了同一个编码，只是分别在 2015 年和 2018 年创建。于是我们只能针对这些冲突单独定制映射表，逐条确认。这种工作没法完全自动化，必须有人去看业务上下文。
第二个雷是外键顺序和循环引用。导入基础数据讲究先父后子，可“物料 - BOM - 工艺路线”之间本身存在循环关系。我们按常规顺序导入，跑到一半发现子表数据已经把父表锁死了。后来只能临时把外键检查关掉，导入完成后再重新启用并做一致性校验。这个动作如果放在生产环境里做，极有可能造成半拉子数据。
第三个雷来自外围系统。客户还有几个自行开发的小程序，负责移动审批和扫码盘点，它们都没有走新系统接口，而是直接读老库表结构。我们在迁移方案里原本只考虑了 ERP 本身，忽略了这个入口。结果导致切换测试时，小程序全部报错。补救方式是在新环境下定制了一个接口适配层，把老系统的 SQL 查询语义重写成对新系统的 API 调用，同时保留小程序端原有的登录逻辑。这让我们得出一个教训：数据迁移从来不只是数据库之间的事，所有和“老数据”握过手的系统，都要纳入范围。
正式切换那天，我们选择了周五晚上 20:00 到周六早上 6:00 的窗口。按照计划，周五 18:00 后禁止新订单录入。可切换时还是出了意外：一位销售在 19:50 通过手机 App 录了一张合同，这张合同没有进冻结快照。周六早上客户发现后，我们紧急从老库增量抓取再补录。问题虽然解决了，但过程非常惊险。后来我们给客户立了一条规矩：停机窗口不是靠通知，而是靠同时关闭 PC 端、移动端、接口入口来保证。只要有一个口子还开着，迁移的起点就不成立。
上线前一个多月，我们组织业务人员参加了多轮用户验收测试。测试用例不是随便编的，而是从真实业务场景里抽取：查一张三年前的销售订单，能不能看到当时的附件？某客户的历史应收余额，和客户自己账上的余额对不对得上？一张“已审批但未过账”的凭证，到了新系统应该是什么状态？这些问题看起来琐碎，却直接关系到数据迁移有没有真正完成。
上线后的“数据后遗症”怎么处理
上线第一周，我们每天凌晨自动执行一次差异比对任务。不要以为切换完成后数据就一定是正确的。比如客户总账余额核对一致，但明细账里有一笔固定资产折旧凭证被重复导入，只是被另一笔负数抵消了，汇总时看不出问题，直到业务人员点开明细才发现。这种问题只有依靠业务抽查和我们的巡检脚本配合才能暴露。
另一个高频后遗症是历史数据查询速度。新系统核心表设计偏向高频交易，没有为十年历史数据建专门的索引。客户财务要查一笔很久以前的凭证，页面要转好几秒。为了不牺牲新系统性能，我们定制了一个历史数据查询界面，支持按单据编号、客户名称、日期范围快速检索，数据来自独立的历史库。这样既保住了业务连续性，又不会拖累日常操作。
权限也是让人头疼的“第四朵云”。老系统里的管理员账号被批量导入新系统后，很多离职员工的账号依然有效，安全审计一眼就能看出问题。我们配合客户做了一轮完整的账号清理，并给新系统启用了定期权限复核流程。这个动作看似和数据迁移无关，但它属于“数据后遗症”的一部分：你把老库搬了过来，也把老库的隐患搬了过来。
常见问题 FAQ
问：老系统数据很乱，是不是应该先做数据清洗再做迁移？
答：不能把数据清洗和迁移分成两个完全独立的阶段。迁移过程本身就是一种清洗，但清洗要按业务优先级推进。基础主数据，比如客户、物料、供应商，必须在上线前完成清洗，否则新系统一出生就是脏的；历史交易单据则可以在“可查询、可追溯、不影响统计”的前提下保留原始样式，不要为了完美而反复修改。关键在于定义一个双方认可的“干净”验收口径，而不是追求每个字段都绝对规范。
问：迁移工具能完全自动化吗？
答：不能。工具可以完成抽取、转换、加载中的重复动作，但字段映射、异常裁决、范围确认，必须由人和业务判断参与。尤其是老系统字段含义与业务规则分离时，自动化只会加速制造错误。我们通常会定制一组自动化巡检脚本和人工抽查机制，让二者配合，而不是迷信“一键迁移”。
问：老系统要不要保留？保留多久？
答：建议保留一段时间，但不要作为业务入口。老系统以只读方式保留三个月到半年，供对账、历史查询和事后审计使用。期间逐步把高频查询场景迁移到新系统形成的新历史库。需要注意，保留不等于放任不管，老库的备份、权限和访问日志也要纳入日常监控，否则它会变成下一个安全薄弱点。
这次经历让我越来越确信，数据迁移不是一次搬运，而是一次对企业既有事实的重建。作为定制开发服务方，我们的职责不是“把数据弄过去”，而是陪着客户一起把过去和未来接上。技术方案再漂亮，也替代不了对业务的敬畏。希望这篇复盘，能帮到正被老系统折磨的同行。
