网站建设中最容易被低估的工作：上线前的数据

一个上线即瘫痪的案例

某电商企业决定更换商城系统。旧系统运行了五年，积累了四万多条商品数据、近十万条会员数据、几十万条订单记录。新系统选型花了两月，开发花了三月，测试花了一月。一切顺利，上线日期定在周末。

上线当天，技术团队把旧系统的数据导出、清洗、转换、导入新系统。从周六早上九点开始，导入商品数据时发现编码规则不兼容，商品图片路径全部失效。紧急写脚本转换，耗时六小时。导入会员数据时发现密码加密方式不同，近十万会员无法用原密码登录。又花了两小时研究解决方案。订单数据导入了三次才成功，每次都要清理重来。

到周日凌晨三点，系统终于勉强上线。周一早上，用户发现购物车里的商品丢失，订单记录不全，收货地址被清空。客服电话被打爆。这个项目的负责人后来在一篇文章里写道：“我们花了八个月选型、开发、测试，却只给数据迁移留了两天。最大的失误不是系统选错了，是低估了数据迁移的工作量。”

数据迁移为什么比想象中难

数据迁移看起来就是“把数据从A系统搬到B系统”。但实际上，两个系统之间的数据结构、编码规则、字段定义、存储格式很少有完全一致的。这些差异在迁移时逐一暴露出来。

编码规则不兼容是常见问题。旧系统的物料编码是自由文本，新系统要求按固定规则生成的编码。旧系统的客户ID是纯数字，新系统要求字母加数字。旧系统的订单状态码有8种，新系统有12种，需要做映射转换。编码不对，数据就进不去，或者进去了一堆乱码。

数据结构有差异也很常见。旧系统的商品表只有一张，新系统拆成了主表、属性表、规格表、图片表。一条商品记录要拆成多条写入不同表。旧系统的地址是一个文本字段，新系统拆成了省、市、区三个字段。拆分规则怎么定，历史数据里各种不规范的写法怎么处理。这些都需要人工判断。

数据质量也是个大问题。旧系统运行多年，数据中普遍存在问题。必填字段为空、格式不符合规范、逻辑矛盾、重复数据、特殊字符。这些问题在旧系统里可能不影响使用，但迁移到新系统时就会被拒绝或者出错。迁移过程也是数据质量的全面暴露过程。

三种数据的不同处理方式

不是所有数据都需要迁移，也不是所有数据都需要用同一种方式处理。

基础数据是指客户、商品、供应商、物料这类主数据。这些数据需要完整迁移，因为它们是业务运作的基础。但迁移前需要做清洗和标准化。客户名称不统一的要合并，商品编码重复的要处理，供应商信息缺失的要补全。基础数据的迁移质量直接影响新系统能否正常使用。

历史交易数据是指订单、发货单、入库单、发票这类历史记录。这些数据迁移的优先级可以低一些。新系统上线后，日常业务依赖的是新产生的交易数据。历史数据更多用于查询和统计分析。可以考虑只迁移最近一两年的数据，更早的数据做归档查询，不必全部导入。

配置和日志类数据的迁移价值通常不高。用户操作日志、系统配置参数、临时缓存数据，这些数据在新系统中会重新生成。一般不需要迁移，或者只迁移关键的配置项。

区分三类数据，把精力和资源集中在最核心的部分，可以大幅降低迁移的工作量和风险。

数据迁移的几个具体工作

数据盘点。迁移前需要搞清楚旧系统里到底有哪些数据、多少条记录、数据质量如何。哪些表是核心业务表，哪些是辅助表。哪些数据可以放弃，哪些数据必须迁移。盘点清楚后才能制定迁移计划。

数据清洗。旧系统中的数据需要先清洗再迁移。重复的记录合并，缺失的字段补全，不符合规范的格式转换。清洗工作可以在旧系统中做，也可以在导出后处理。但一定要在迁移之前完成，不能在导入新系统后再改。那时候改的成本更高，因为数据已经分散到多个表中了。

规则映射。旧系统和新系统的数据字段需要一一对应。旧系统的状态字段有A、B、C三个值，新系统有甲、乙、丙、丁四个值，需要明确映射规则：A对应甲，B对应乙，C对应丙，丁没有对应如何处理。规则的制定需要业务部门参与，因为涉及到业务含义的转换。

迁移验证。数据导入后需要验证准确性和完整性。抽样检查关键数据，对比新旧系统的统计结果。商品总数是否一致，订单总额是否对得上，客户数量是否匹配。验证工作需要业务部门参与，因为他们最清楚数据应该是什么样的。

回滚方案。迁移万一失败，需要有回滚方案。备份旧数据，保留旧系统。出现问题能在多长时间内切回旧系统，要提前约定好。没有回滚方案的迁移，风险很高。

新易编码在数据迁移中的角色

新易编码不直接做数据迁移，但它可以降低迁移的难度和后续维护的复杂度。

迁移前如果有物料编码不统一的问题，可以在新易编码中先建立统一的编码体系，然后把新旧编码的映射关系维护好。迁移时，新系统直接使用统一编码。迁移后，新系统中不再有编码混乱的问题。

迁移时发现客户名称不一致、供应商名称有多个版本，可以在新易编码中建立标准名称和别名的对应关系。迁移工具根据别名匹配，将不同叫法的客户映射到同一个标准编码下。迁移完成后，新系统的客户数据就是干净的、一致的。

迁移后新系统上线，物料编码、客户编码、供应商编码的日常维护由新易编码负责。新系统中的编码规则不会频繁变动，编码质量有持续监控。迁移不只是搬一次数据，而是建立一个可持续维护的体系。

几点具体的建议

给数据迁移留出足够的时间。不要等项目开发完了才开始考虑迁移。在项目计划阶段就把数据迁移的工作量估算进去。通常，数据迁移的工作量占总项目工期的15%到25%是正常的。如果项目总工期是六个月，迁移至少需要一个月。

迁移前先做一次数据质量评估。导出数据样本，看看问题有多严重。重复率多少，缺失率多少，格式不一致的比例多少。用数据说话，而不是凭感觉判断。评估结果会直接影响迁移方案的复杂度和时间预算。

先迁移测试环境。不要在正式环境上第一次跑迁移脚本。在测试环境中多次演练，每次记录发现的问题，修改脚本，再跑一次。测试环境跑通了，正式迁移才会有把握。

准备迁移手册。迁移步骤、检查清单、常见问题的处理方法、回滚操作流程，全部写下来。迁移时按照手册操作，减少临时决策。手册也是知识转移的一部分，不只是给执行者看的。

上线后保留旧系统一段时间。新系统运行稳定后，旧系统可以只读访问。用户需要查询历史数据但新系统中没有迁入的，还可以访问旧系统。三个月到半年后，确认新系统已经覆盖了所有查询需求，再关闭旧系统。

结语

网站建设项目中，功能开发、界面设计、性能优化通常会获得最多关注。数据迁移常常被当成“技术活”，到了项目后期才开始处理。但很多项目的延期和上线后的故障，根源都在数据迁移。

数据迁移不是简单的“搬数据”，它包括了数据盘点、清洗、映射、验证、回滚等多个环节。每个环节都有各自的工作量和风险。低估任何一环，都可能导致迁移失败。

新易编码不解决所有迁移问题，但它从编码标准化的角度降低了迁移的难度。迁移时编码统一了，迁移后编码不再乱变。数据迁移是一个一次性项目，但编码管理是一个持续的工作。两者结合，迁移的效果才能保持住。

把数据迁移当作项目中独立的工作阶段来规划，给它足够的时间和足够的重视。

 

如果您有物料编码相关的问题，欢迎咨询新易物料编码