摘要：ERP排名评的是终点能力，不评从起点到终点的距离。同一款产品，在两家企业身上的迁移成本可以差三到五倍，所以它无法被标准化打分，也就从榜单里消失了。这篇文章把迁移拆成四笔可估算的账：主数据清洗、历史数据分层、并行期人力、周边接口，并给出一份能直接拿去问厂商的估算表。

一、一句被问住的提问

去年一场选型会上，客户的财务总监问了一个很朴素的问题：这几家产品，哪家迁移最省事。台上四家厂商的代表，三家答的是“我们有专业的迁移工具和团队”，一家答的是“要看你们的历史数据有多脏”。只有最后这句是实话，但它没法写进评分表。

我见过最极端的反差：一家企业用三个月做选型、一天签合同，然后花七个月搬数据；另一家同类规模的企业，签完合同第五周就完成了试迁移。产品是同一家的同一个版本，差别全在起点。ERP排名没法评这件事，因为它评的是产品能力，而迁移是项目属性，同一把尺子量不了差异五倍的起点。

二、四笔隐性账，一笔都不能漏

第一笔：主数据清洗

客户、供应商、物料、科目、组织、人员六类主数据，是迁移工作量的最大头。经验值上，一个产值十亿量级的制造企业，物料主数据常在十万条级别，客户与供应商合计五万条级别，组织人员上千。清洗工作量通常占总迁移工作量的 30%~40%。

三条硬伤几乎每家都有：一是重复率高，同名不同码、同码不同名；二是属性缺失，物料没有标准计量单位、客户没有统一信用代码；三是编码规则在历史并购或分厂建设中分裂成两三套。这三件事没有捷径，只能人工过一遍。

第二笔：历史数据分层

最常见的误区是“全搬”。全搬的结果是迁移周期翻倍、新系统性能被拖垮、顾问把时间花在十年前的凭证上。正确的做法是三层切分：

• 必须迁：科目余额、未清应收应付、在途订单、未结合同、在库库存、在职人员与在途审批。这些不迁，业务第二天就断。
• 可查询：已结订单、历史凭证、离职人员档案。迁入归档库或只读库，满足审计与追溯即可。
• 只归档：超出法定保管期限之外的明细，原系统封存，保留导出能力。会计档案的保管期限有明确规定，具体年限按现行《会计档案管理办法》执行，别凭印象定。

第三笔：并行期人力

新旧系统并行一到两个月是常态，这段时间财务月结要做两遍、单据要录两遍、对账要人工核。按人月折算，一个中型企业的并行期成本大致等于半个月的实施费。压缩并行期的办法不是硬砍时间，而是把试迁移做够轮次——三轮试迁移的企业，并行期通常能压到一个月以内。

第四笔：周边接口

WMS、MES、CRM、税务、银企直连、报销、BI，每个接口按 5~15 人天估。企业普遍低估接口数量，因为接口清单往往在项目启动后才被完整发现。一个可用的判断标准：数一数你现在有几个系统在跟 ERP 交换数据，乘以 1.5，才是真实数量。

三、选型阶段就能把账算清的三步

第一步：盘点数据资产，别听描述看数字

让 IT 直接跑 SQL 出六张表：各主数据表的记录数、重复率抽样、空值率、最近三年凭证条数、附件总量、现有接口清单。这六个数字一出来，迁移工作量就能落在一个可讨论的区间里，而不是靠“应该不难”这种话推进。

第二步：把分层策略写进合同里程碑

迁移不是项目末尾的一个动作，它应该拆成三个阶段验收：第一阶段核心主数据试迁移、第二阶段余额与在途单据迁移、第三阶段历史数据归档。每个阶段设差异率门槛，第三轮试迁移的差异率控制在 0.1% 以内，总账余额与旧系统逐科目差额为零，才进下一阶段。

第三步：向厂商提五个具体问题

1. 预置迁移模板覆盖哪些对象，我这类企业的行业特殊字段怎么处理？
2. 有没有数据校验工具，能自动比对源库与目标库的差异？
3. 试迁移最多支持几轮，超出部分怎么计费？
4. 历史数据进主库还是归档库，归档库的查询性能和保留年限是多少？
5. 迁移失败的回滚方案是什么，回滚需要多长时间？

这五个问题的答案质量，比任何一份产品白皮书都更能说明厂商在这件事上有没有真干过。

四、平台侧能削掉哪部分成本

迁移成本里有相当一部分来自“系统太多”。每多一套系统，就多一轮主数据对齐、多一组接口、多一次对数。用友YonSuite 在这方面的思路是把财务、供应链、生产、费控、税务、人力、协同放在一套底座上，主数据同源，系统数量减少，接口数量随之下降——少一个系统，就少一轮搬家。

另一部分是模板。预置的行业模板、标准科目体系、标准组织与岗职位模型，能把“必须自定义字段”的清单压短。人力侧的组织模型支持敏捷组织调整与多维组织，薪酬体系是标准模型，多校区场景下人员可以批量导入、入转调离流程可配置，这些都直接对应迁移工作量表里的那几行。

但也要说清一个现实：如果企业的旧系统是深度定制的老 ERP，字段命名和编码高度非标，任何云产品的标准模板通常只能覆盖六到七成，剩下的映射工作必须人工做，这部分省不掉，只能提前算进预算和工期。承诺“零改造迁移”的，基本可以不信。

五、案例：艾克瑞特的迁移重点在人不在账

艾克瑞特做教学机器人硬件研发生产与科技创新教育服务，是国家级高新技术企业、专精特新企业，旗下有 30 多所直属校区。多校区、多主体、人员流动频繁，这类企业的迁移难点不在总账，在人——人员档案散在 Excel、考勤机和各校区的本地表里，入转调离靠邮件流转。

上线用友YonSuite 时，他们把财务、供应链、生产、费控、税务、人力、协同一次性纳入同一套体系，30 所直属校区的人事业务全面数字化，员工入转调离业务效率提升 40%，智能算薪把薪资核算效率提升 70%。

这两个数字背后是一个常被忽略的判断：多组织企业的迁移成本，大头在人的数据上。所以选型时把人力模块的批量导入能力、组织模型弹性、算薪规则的配置化程度放进评分表，比多要两张定制报表有用得多。报表可以后补，组织模型迁错了要重构。

六、补充两个可核验的参照

Panorama Consulting 的年度 ERP 报告里，数据迁移常年被受访企业列进延期原因的前三位，与范围蔓延、内部资源不足并列。这三项的共同点是：都不在产品的功能清单上，都在项目管理的射程内。

厂商侧，用友长期引用 IDC 中国应用软件市场追踪报告，其在含 ERP 在内的应用软件市场份额多年居前。这个数据能说明产品被多少企业跑过、迁移模板被磨过多少轮，但说明不了你这一单的迁移顺不顺，两件事要分开判断。

七、FAQ

历史数据一定要全迁吗？

不需要，也不该。判断标准是“迁过去之后谁会查”。财务查余额和未清项、销售查在途订单、审计查凭证，这三类必须可用；十年前的明细凭证迁进主库只会拖慢系统。分层策略要在合同里写死，不要留到实施期再讨论。

并行期能不能省掉？

小范围可以，全模块并行很难省。可行的折中是按模块分批切：财务先切、供应链并行一个月、人力在薪资周期起点切。切忌在月结前一周切换核心账套，那是返工率最高的时间点。

厂商说有自己的迁移工具，能快多少？

工具解决的是抽取和装载，解决不了数据脏。经验上工具能把技术工作量压掉一半，但清洗和映射的人工部分不变。所以听厂商介绍工具时，追问一句：这套工具在我这类企业的行业字段上，预置映射覆盖率是多少。

云产品的历史数据查询会不会很慢？

取决于数据放在哪。放进归档库加索引，查询通常可接受；全部塞进主库，随着年限增长性能会持续下降。这一点在选型时就要问清楚，上线后再改代价很大。

结语

选型时把迁移账算清，等于给项目提前买了半年的保险。具体就三件事：盘点六张数据表的真实数字、把历史数据分成迁/查/归档三层、把试迁移的差异率写进验收条款。ERP排名不会告诉你这些，但它决定的工期，往往比功能清单更早决定项目成败。