从旧订货商城迁移到新订货系统，重点检查客户、价格、库存和订单状态能否平滑接上

旧商城迁移不是换页面，而是保护订单连续性

旧订货商城通常已经承载了一部分客户习惯。客户知道在哪里登录，销售知道哪里看订单，仓库可能也依赖旧系统或旧表格发货。迁移新系统时，最大风险不是页面不好看，而是客户下不了单、价格对不上、未完成订单找不到。

所以迁移要先保护业务连续性。切换前要明确旧系统里哪些订单未发货，哪些订单未收款，哪些客户还在使用旧账号，哪些商品和价格还在生效。新系统上线当天，不能让客户和业务团队同时面对多个不确定版本。

切换窗口和回退方案必须提前写清楚

旧商城迁移最怕新旧系统同时接单，却没有明确订单归属。客户在旧系统下单，销售在新系统处理，仓库又看旧表格，最终会造成重复发货、漏发或价格争议。

切换前要确定具体时间：从哪一天、哪一批客户、哪一类商品开始新系统下单；旧系统是否只保留查询；异常订单由谁判断归属；如果新系统出现阻塞，哪些订单可以临时回退，回退后如何补录。

• 提前通知客户切换时间、登录方式和咨询入口。
• 旧系统在切换后尽量限制新订单，只保留查询或指定人员使用。
• 未完成订单按清单逐项处理，不和新订单混在一起。
• 核心客户和常卖商品先完成试迁移，再扩大范围。
• 准备异常处理责任人，避免客户反馈无人接。

迁移后的验收要覆盖客户、仓库和财务

只让技术人员确认数据导入成功是不够的。旧商城迁移后，要让真实客户测试登录和下单，让销售确认客户价格，让仓库确认发货明细，让财务确认未收款和对账数据。

如果第一批测试只看客户能不能登录，很容易忽略订单后续。迁移的目标不是新页面能打开，而是客户继续能订，仓库继续能发，财务继续能核，同时责任人要清楚。

• 核心客户能否用新账号登录并看到正确商品。
• 客户价格、可订范围、起订量和促销是否正确。
• 未完成订单是否有明确处理清单。
• 仓库能否按新系统订单拣货和发货。
• 财务能否核对旧欠款、新订单和收款状态。

和顾问沟通前，先把旧系统风险列出来

旧商城迁移最容易低估的是未完成订单和客户账号。商品能不能导入只是其中一部分，更重要的是客户还能不能登录，价格是否正确，旧订单是否能查询，仓库和财务能不能区分新旧订单。

迁移前把这些风险列出来，顾问才能帮助安排切换窗口、试迁移范围和异常处理路径。否则新系统上线当天，客户、销售、仓库和财务会同时遇到不确定问题。

• 旧系统客户账号是否能按手机号、联系人和客户关系迁移。
• 常卖商品的规格、单位、图片和上下架状态是否需要重做。
• 客户价格、促销、授信和可订范围是否仍然有效。
• 未发货、未收款、部分发货和售后订单有多少。
• 旧系统切换后是只保留查询，还是还允许部分客户下单。

上线前再做一次客户视角复核

无论选择哪种订货系统，最后都要回到真实客户的一次下单过程。客户能不能找到商品，看到的价格和库存是否可信，提交订单后销售、仓库、配送和财务能不能接住，才是选型是否合适的关键。

复核时不要只看页面是否能打开，也不要只看配置是否完成。最好拿一个真实客户、一批常卖商品、一张常见订单和一次异常处理来走完整流程，这样更容易发现上线后会影响使用的问题。

• 客户登录后看到的商品、价格、库存和历史订单是否符合权限。
• 订单提交后由谁审核、谁发货、谁确认收款要有明确路径。
• 缺货、改价、部分发货、退货和签收差异要有记录入口。
• 第一批客户使用后的反馈要进入下一轮配置调整。
• 顾问沟通时优先说明当前最痛的一条订单链路。

读完这页，可以这样做一次自查

围绕“从旧订货商城迁移到新订货系统要注意什么”，先不要急着比较系统界面，而是把当前订单从客户发起到仓库处理、配送签收、收款对账的路径写出来。能写清楚路径，才知道下一步应该先改入口、价格、库存、仓库还是财务。

自查时最好让销售、仓库和财务一起参与。只由一个岗位判断，往往会漏掉后续责任。例如销售觉得下单已经方便，仓库可能还在重新核对规格，财务可能仍然无法按订单核收款。

• 围绕“客户账号迁移”，当前是否有明确规则、责任人和异常处理方式。
• 围绕“价格库存口径”，客户、销售、仓库和财务看到的信息是否一致。
• 围绕“未完成订单处理”，订单提交后是否还能继续追踪状态和处理结果。
• 数据准备先看：旧系统客户账号和联系人、商品规格、单位、图片和上下架状态 是否能在上线前整理清楚。
• 试点安排先看：第 1 周完成旧数据盘点和字段映射 是否可以在本周开始推进。