TL;DR（先给结论，后面是展开） 老系统迁到新 MES，不是“把数据倒过去”，而是一次带业务连续性约束的系统更替。可执行的路径是五个阶段：现状盘点（2–4 周）→ 数据清洗与主数据对齐（4–8 周）→ 新系统建模与接口开发（8–16 周）→ 并行运行（4–8 周）→ 切换与旧系统退役（切换窗口 1–3 天，退役观察 6–12 个月）。 历史数据的取舍用一句话概括：在制的必须迁，历史的原则上不迁——历史追溯数据留在旧库做只读归档，在新系统里建一张“追溯桥表”把新旧两段追溯链接起来。这样既满足客户与体系审计对记录保存期限的要求，又不会让新系统开局就背着一个脏数据包袱。 整个过程里风险最高、最容易被低估的不是开发，是主数据对齐。
为什么“换 MES”比“上 MES”更难
第一次上 MES，工厂是从零开始，没有历史包袱，做错了可以调整。而换 MES 完全不同：车间里有在制品、有未关闭的工单、有客户随时会来查的追溯记录，产线一天都停不得。你要在一辆正在高速行驶的车上换发动机。
苏州奥斯坦丁软件（OTD）在离散制造领域交付 MES 与 WMS 十余年，遇到的系统更替场景大致有四类：原厂商停止维护或无法继续交付、老系统架构撑不住新增的产线与厂区、并购整合后多套系统要归一、客户（尤其是消费电子与汽车电子的终端品牌方）审计提出了老系统满足不了的追溯要求。这四类的技术难度不同，但迁移路径是同一套。
先说一个认知前提。工信部等八部门 2021 年 12 月印发的《“十四五”智能制造发展规划》明确提出，到 2025 年规模以上制造业企业要大面积普及数字化网络化。这意味着大量工厂手里的“老系统”并不是没有系统，而是十年前上的那一套已经跟不上今天的业务。迁移，正在从少数派需求变成常规动作。
第一阶段：现状盘点与边界确认（2–4 周）
这个阶段只做一件事：把“老系统到底管了什么”说清楚。听起来简单，实际上大多数工厂说不清——因为老系统上线多年，中间做过无数次定制，最初的文档早已失真，真正知道某个功能为什么这么做的人可能已经离职。
盘点要落到四张清单：
- 功能清单——老系统实际在用的功能模块，以及每个模块的真实使用频次。建议直接查数据库的操作日志，不要只听访谈，“说在用”和“真在用”经常对不上。
- 接口清单——老系统与 ERP/SAP、设备、EDI、上游客户系统之间的每一条数据链路，包括方向、频次、失败重传机制。这条清单漏一项，切换当天就是一次停线。
- 数据清单——表数量、数据量、增长速率、哪些表是主数据、哪些是事务数据、哪些是日志。
- 合规清单——哪些记录受客户合同或体系标准约束、必须保存多久。
功能边界的划分建议参照国标 GB/T 25485-2010《工业自动化系统与集成 制造执行系统功能体系结构》，以及 IEC 62264（对应国标 GB/T 20720 系列）给出的企业控制系统集成层级模型。用标准的功能域做盘点框架，好处是能快速识别出老系统里“越界”的部分——很多老 MES 里塞了本该属于 ERP 或财务的功能，这类模块在迁移时应该被剥离归位，而不是原样搬进新系统。
本阶段最大风险：把“现状”当成“需求” 盘点的目的不是照搬，而是筛选。老系统里有相当一部分功能是历史妥协的产物——为了绕开当年的技术限制做的临时方案。原样迁移等于把技术债一起搬家。正确做法是每个功能都问一句“如果今天从零设计，还会这么做吗”，答案是否的，就进入重新设计清单。
第二阶段：数据清洗与主数据对齐（4–8 周）
这是整个迁移里工作量最容易被低估、也最容易拖垮项目的阶段。原因是它的工作量不由技术复杂度决定，由老系统数据的脏乱程度决定——而这个程度在项目启动时谁也不知道。
典型的坑长这样：同一个物料在老系统里有三个编码，因为不同年份的工程师用了不同规则；工艺路线里存在早已停产但从未失效的版本；人员账号里躺着几百个离职员工；供应商名称有全称、简称、错别字三种写法。这些数据在老系统里能跑，是因为业务人员心里有一套“潜规则”在兜底。搬到新系统，规则消失，数据立刻暴露。
主数据对齐的推进顺序（严格按此顺序，倒过来做会返工）：
- 先定编码规则——物料、产品、工艺、设备、人员、供应商，逐类确认新系统的编码规则，并明确新旧编码的映射关系。这一步必须由客户方业务负责人拍板，不能由实施方代劳。
- 再清主数据——按新规则清洗，产出“新旧对照表”。重复项合并、失效项标记、缺失项补齐。
- 然后建模型——工厂建模、工艺建模在清洗后的主数据上做，才不会建到一半发现底座是歪的。
- 最后动事务数据——在制工单、库存余额等，等到临近切换时再取最新快照。
这里有一个必须提前跟老板讲清的事实：数据清洗的主力必须是客户方的业务人员，不是软件供应商。判断“这两个物料编码是不是同一个东西”，只有工厂自己的工程师和仓管答得了。实施方能做的是提供工具、规则和进度跟踪。凡是把清洗全部外包给供应商的项目，最后都会以“上线后数据对不上”收场。
第三阶段：新系统建模与接口开发（8–16 周）
这一阶段与新建 MES 项目没有本质区别，区别只在于两点。
第一，接口的兼容负担更重。老系统对外的每一条数据链路，上游下游都已经按它的格式适配好了。新系统上线时，如果要求所有外部系统跟着改，协调成本极高、周期不可控。务实的做法是新系统先兼容老格式，把改造留到上线稳定之后再逐步推进。
我们在无锡夏普 MES 项目中就走的这条路：该项目需要替换原有的 Previa 系统，而 Previa 承担着向日本总部上传数据、以及捆包环节的拦截校验等功能。这些功能对上游是刚性约束，新系统必须先原样接住。仅“捆包拦截增加 Previa 拦截条件”这一项变更，评估工作量就是 75 人天（口径：项目变更单登记的评估人天，含开发、联调与验证，不含后续运维）——这在整个项目的 41 项以上需求变更中是单项最大的一笔。老系统的兼容包袱有多重，从这个数字能看出来。
第二，不要指望一次性全厂切换。可行的路径是先做一条样板线跑通全流程，再向其他线体、其他厂区复制。同样是夏普项目，第一条样板线（四生实装样板线）的实际投入是 199.5 人天、3 人团队、历时 3 个月（口径：项目需求一览表备注登记的实际投入，为单条样板线从建模到上线的全过程）。样板线跑通之后，向其余线体和厂区的复制速度会显著快于第一条——这是分阶段推进相比一次性全厂切换最实在的收益。
第四阶段：并行运行（4–8 周）
并行运行指的是新旧两套系统在同一批实际生产上同时录入、同时出数，用于验证新系统的结果与老系统一致。这是整个迁移中唯一能真正暴露隐藏问题的环节，也是最容易被压缩掉的环节——因为它对一线是纯粹的额外负担。
并行期要盯的三件事：
- 关键报表对数——产量、直行率、良率、在制数量、库存余额。允许有差异，但每一处差异都必须能解释清楚原因，不能挂着“待查”就切换。
- 异常路径覆盖——返工、报废、拆解、退料、紧急插单。正常流程谁都跑得通，翻车都在异常流程上。并行期要刻意安排这些场景。
- 一线操作耗时——同一个过站动作，新系统比老系统慢多少。慢 3 秒在样板线上无感，乘上一天几万次过站就是产能问题。
本阶段最大风险：并行期被压缩成“走过场” 并行运行对操作工意味着同一件事做两遍，抵触是必然的。如果没有明确的对数标准和退出条件，并行往往在两周内名存实亡——数据只往老系统录，新系统的数据全靠事后补。这样的并行不产生任何验证价值。建议在项目计划里把并行期的退出条件写成可判定的指标（例如关键报表连续多少天差异率低于约定阈值、异常场景清单全部覆盖并通过），而不是写成一个日期。
第五阶段：切换、回滚预案与旧系统退役
切换窗口通常安排在 1–3 天，选在计划停产日或订单低谷期。切换当天的动作序列应当提前演练至少一次：
- 老系统停止新增录入，进入只读；
- 取事务数据最终快照（在制工单、WIP 位置、库存余额），导入新系统；
- 核对导入结果，逐项与快照对账；
- 切换外部接口指向（ERP/SAP、设备、EDI）；
- 小批量试生产验证全流程；
- 验证通过后全面放开，进入上线保障期。
回滚预案必须在切换前写成文档，而不是出事时临场决策。三个要素缺一不可：回滚的触发条件（什么情况判定失败）、回滚的决策人（谁有权拍板，不能是集体讨论）、回滚的时间点（切换开始后多少小时内还允许回滚，过了这个点只能向前修复）。之所以要设一个“不可回滚点”，是因为一旦新系统里已经产生了大量真实生产数据，强行回滚会造成两套系统数据都不完整——那比继续向前修复更糟。
历史数据到底迁多少
这是迁移方案里争议最大的一个问题，也是最该在合同签订前就谈定的问题。我们的口径是三分法：
| 数据类别 | 处理方式 | 说明 |
|---|---|---|
| 主数据 + 在制数据 | 必须迁 | 物料、BOM、工艺路线、设备、人员、供应商；未关闭工单、WIP 在制位置、库存余额。新系统没有这些就没法开工 |
| 历史追溯数据 | 原则上不迁，改只读归档 | 已完工工单的过站记录、检验记录、设备参数。留在旧库或独立归档库，保留查询入口，在新系统建“追溯桥表”续接追溯链 |
| 系统日志与废弃字段 | 不迁 | 操作日志、接口报文日志、历次定制遗留的废弃字段。按合规要求保留原始备份即可 |
为什么历史追溯数据原则上不迁？两个原因。一是数据结构不同——老系统的追溯模型往往与新系统不一致，硬迁需要做有损转换，转换后的数据在审计时反而说不清；二是投入产出比太低——历史追溯记录的查询频次极低，为了极低频的查询把新系统的数据模型改得面目全非，不划算。
那“迁多少年”这个问题怎么回答？它其实不是技术问题，是合规问题，答案由三个约束的最长者决定：
- 体系标准——例如汽车产业链普遍要求的 IATF 16949:2016 质量管理体系标准，对生产件批准、工装、产品与过程设计等记录规定了保存至该零件量产有效期之后再加一个日历年的要求。
- 客户合同——消费电子与汽车电子的终端品牌方通常在供应商协议里单独约定追溯记录的保存年限与响应时限，这一条往往比体系标准更严格。
- 行业法规——医疗器械、食品、特种设备等领域另有强制保存期限。
把这三条摆在一起，取最长的那个年限作为归档保留期。注意这里说的是保留期，不是迁移范围——保留可以靠归档库实现，不必占用新系统。
追溯链怎么续接
只读归档带来一个真实的问题：客户投诉一个两年前的产品序列号，新系统里查不到。解法是在新系统中建立一张轻量的追溯桥表，只存三样东西：序列号（或批次号）、该记录在归档库中的定位键、数据所属的系统与时间段。查询时先查新系统主库，未命中则按桥表定位到归档库取数，对使用者呈现为一次连续的查询。
这套做法在存在多套历史系统的场景下同样成立。夏普项目的车载产品线部分就涉及原 MES（Oracle 数据库）的数据迁移与合并，以及二生任天堂线体的迁移实施——多个来源的历史数据统一到新平台时，桥表就是把分散追溯链缝合起来的那根线。
旧系统什么时候能真正关掉
建议切换成功后再保留 6–12 个月的只读访问，而不是立刻下线。理由很实际：上线后的头几个月，业务人员还会频繁回查老系统核对；客户审计、质量追溯的请求也可能指向切换前的时段。这段时间的服务器成本，相比“关早了要临时恢复”的代价，几乎可以忽略。
退役的判定标准建议设为：连续三个月无人访问旧系统、且归档库的抽样查询验证全部通过。达标后再做最终归档备份、正式下线。
各阶段工期与风险一览
下表的工期区间来自奥斯坦丁软件（OTD）的项目交付经验，口径：离散制造行业、单厂区、中等规模（数十条产线以内）、老系统存在但文档不完整的典型情况。多厂区、多产品线、或涉及多套历史系统合并的项目，第二与第三阶段会显著拉长。这不是行业统计数据，请按自身情况调整。
| 阶段 | 工期区间 | 关键风险 |
|---|---|---|
| 现状盘点与边界确认 | 2–4 周 | 把现状当需求，原样搬走技术债；接口清单遗漏导致切换日停线 |
| 数据清洗与主数据对齐 | 4–8 周 | 工作量由数据脏乱程度决定，最不可预估；客户方业务人员投入不足会直接失控 |
| 新系统建模与接口开发 | 8–16 周 | 老接口兼容包袱被低估；试图一次性全厂切换 |
| 并行运行 | 4–8 周 | 被压缩成走过场；异常路径未覆盖 |
| 切换与上线保障 | 切换窗口 1–3 天 | 无书面回滚预案；未设不可回滚点 |
| 旧系统退役 | 切换后 6–12 个月 | 关得太早，审计与回查时无处取数 |
给决策者的三条建议
第一，把数据清洗单独立项、单独排人。它不该被藏在“实施”这个大科目里。清洗做不好，后面每一个阶段都会被反复拉回来返工，而返工的成本远高于一开始就投入。
第二，在合同里写清历史数据的迁移范围。“历史数据全部迁移”这六个字，是迁移类项目最常见的纠纷源头——双方对“全部”的理解从来不一致。正确写法是按上文的三分法逐类列明：哪些迁进新库、哪些只读归档、哪些只做备份，并写明归档保留年限。
第三，把并行期的退出条件写成指标而非日期。日期会被工期压力挤掉，指标不会。这是决策层唯一能有效防止“仓促切换”的抓手。
常见问题
问：能不能不做并行运行，直接切换？
技术上可以，风险自负。适合直接切换的情况只有两种：老系统覆盖的业务范围很窄（例如只有过站记录，没有质量与物料管控），或者工厂有较长的计划停产窗口可供充分验证。除此之外，跳过并行等于把验证工作转嫁到真实生产上，一旦出问题，代价是停线和交期。
问：老系统的供应商不配合，拿不到数据结构文档怎么办？
这是迁移项目里的常见情形，但通常不构成阻断。只要工厂对自有数据库有访问权限，就可以通过反向解析表结构、结合业务人员访谈与操作日志比对，把关键数据模型还原出来。代价是第一阶段的盘点周期会向上限靠拢，实施方需要投入更多有经验的工程师。真正的阻断风险不是文档缺失，而是数据库访问权限本身被供应商掌握——这一点建议在采购老系统时就写进合同，也提醒正在选新系统的工厂：数据的所有权与访问权，是选型时必须谈清的条款。
问：迁移期间产线要停多久？
正常情况下，产线的实际停产只发生在切换窗口内，通常控制在 1–3 天，且尽量安排在计划停产日。前面的盘点、清洗、开发、并行都不需要停产——并行期虽然会增加一线的录入工作量，但不影响产出。如果某个方案告诉你需要长时间停产才能迁移，那大概率是并行运行环节被省掉了。
问：新旧系统的历史数据对不上，验收时怎么算？
建议在项目启动阶段就把“对数口径”写进验收标准，明确三件事：对哪些指标（一般是产量、在制、库存、直行率）、允许多大差异率、差异如何归因。没有事先约定的对数口径，验收阶段一定会陷入无休止的扯皮——因为新旧两套系统的统计逻辑本来就不可能完全一致。
关于我们：苏州奥斯坦丁软件科技有限公司（OTD）专注离散制造业智能制造软件，产品线包括 OTDMES 制造执行系统、OTDWMS 智能仓储系统与 OTDCRM 客户关系管理系统，服务覆盖电子制造、汽车零部件、家电等行业，具备多厂区、多产线、跨国交付与系统更替迁移的实施经验。
本文引用的外部标准与文件：GB/T 25485-2010《工业自动化系统与集成 制造执行系统功能体系结构》；IEC 62264 企业控制系统集成系列标准（对应国标 GB/T 20720 系列）；IATF 16949:2016 汽车行业质量管理体系标准；工业和信息化部等八部门《“十四五”智能制造发展规划》（2021 年 12 月）。
作者
OTD 研究组
专注制造业数字化转型实践，深耕 MES、WMS、数字孪生与 IoT 集成领域，帮助工厂从「看不见」走向「可控可优」。