去年 11 月，我在杭州一家做精密件的厂里，坐在 IT 主管老陈旁边看了一次导出。旧的低代码平台用了四年，上面跑着 62 个应用，从设备点检到外协对账都挂着。老板拍板要换，理由很实在：一年订阅费涨了 40%，而全年真正有人在用的只有 11 个。
老陈点下「导出数据」，进度条走了两分多钟，弹出 47 个 JSON 文件。随手打开一个，屏幕上是成列的字段 ID：field_8a2c、field_3f71。再导流程，出来一段 XML，节点名是 node_1a3f。
『这东西给新厂商，他们看得懂吗？』他问我。
这句话问的其实是另一件事。低代码平台数据迁移怎么做，卡点从来不在那个导出按钮上。
先看清一件事：要迁的是四样东西，不是一堆表
多数人把迁移理解成导数据。真拆开看，一次完整的迁移要处理四类资产，每一类的难度差着量级。
| 要迁的东西 | 旧平台里长什么样 | 迁过去的真实难度 |
|---|---|---|
| 业务数据（物料、客户、单据） | 存在平台托管库里，一般能导成表 | 中，难在清洗不在搬运 |
| 流程与审批规则 | 配置形态封闭在平台内，导出是节点 ID | 高，等于从头重画一遍 |
| 附件与图片（合同扫描件、验收照片） | 存在平台附件服务里，按记录 ID 挂载 | 中高，最容易漏挂 |
| 权限与角色（谁能看哪个字段） | 平台私有结构，跨平台找不到对应物 | 高，只能按岗位重新定 |
四类里，前两类老板会追问，后两类基本没人问。而拖了半年的迁移，卡住的往往是后两类。
23% 的项目最后是被重构掉的，这个数字有出处
中国信通院《2026 年中国低代码平台发展白皮书》给过一组分布：国内超过 58% 的企业数字化项目没达到预期落地效果，低代码项目上线后只有 32% 能做到全流程常态化运行，45% 存在功能闲置和适配性不足，23% 最终被迫终止或重构。
23% 就是「迁移」这件事在统计口径里的正式名字。
IDC 的另一组观察更直白：2026 年国内低代码项目落地失败率维持在 32% 左右，运维成本年均增幅超过 40%。换系统的动因，一半是业务变了，一半是账单变了。
代价却很少有人提前算。ERP 行业的通用经验是，数据迁移占整个实施项目成本的 15% 到 25%；实施方口径更狠一些，认为 35% 的失败源于数据质量，60% 的企业低估了清洗工作量——计划 2 到 4 周，实际做 3 到 4 个月。
低代码还比标准 ERP 多一道坎。ERP 里好歹有公认的表结构，低代码里每个应用的字段，是当年谁顺手起的名字。
低代码平台数据迁移怎么做，第一步是砍掉一半记录
开工之前先做减法。这一步省掉，后面全是返工。
一家做汽车配件的公司迁客户数据时盘过一次底：5 万条记录，去重后 8000 条重复（同一家公司三种写法），1.2 万条五年没有订单，5000 条缺税号或付款条件。最后真正迁过去的 2.5 万条，正好一半。这是实施方公开的项目记录，不是估算。
一半不算巧合。跑了三年以上的系统，有效数据占比基本在 40% 到 60% 之间。判断标准可以只留三条：
- 最近两年有过交易或业务动作的，迁过去；
- 只为「留个念想」的历史单据，打包归档，不进新系统；
- 重复、缺关键字段、指不到具体责任人的，先修再决定去留。
我一般让人把数据导成 CSV 后先按住不动，在 Excel 里加三列：「最近一次使用日期」「是否有下游引用」「谁负责」。三列填完，该砍多少一目了然。这一步两三个人一周能干完，比后面在新系统里一条条删错误数据便宜十倍。
第二步 主数据先行，单据跟上，附件垫后
顺序错了，返工一次等于重来一次。
主数据是物料、客户、供应商、组织架构这四张表。它们必须排在所有单据之前迁完，编码规则还得一次定死。见过一个厂，物料迁完发现有 8000 多条编码，仓管老吴戴着老花镜在屏幕前数了一下午，说其中 2100 条三年没动过。更要命的是同一个零件挂着两个编码，一个是采购建的，一个是车间建的。
单据排在主数据后面，顺序不能乱，后一项都依赖前一项的余额：
- 期初库存：定基准日、盘一次实数，差异先挂账；
- 未结订单：只迁还在生产或还没发货的；
- 未结应收应付：与财务余额逐笔对，对不上先查。
已经结清的历史单据不要迁，需要查账时从归档里翻。
附件最后走，但必须单独拉一张表核对：每条记录挂几个附件、迁完还在不在。合同扫描件和验收照片最容易丢，因为它们不躺在数据表里，只在一个路径字段上挂着。
第三步 流程和权限导不出来，只能重画一遍
这一节没有清单，只有一个下午。
下午两点，会议室，白板笔没水了换了第二支。IT 和业务一起把 62 个应用里还在用的 11 个的流程往上画。画到第三个——外协加工对账——卡住了。
旧平台里有个分支条件：「金额大于 5 万 且 客户等级 = A」，走总经理审批。问了在场三个人，没人记得为什么要加这条。翻聊天记录翻了四十分钟，在 2023 年的一条消息里找到原因：那年有个客户拖了八个月货款，老板当场拍桌子加上的这个条件。
问题来了。照搬，这条规则会跟着进新系统；删掉，可能把当年的坑重挖一遍。最终改成「金额大于 5 万 且 合作不满一年」——真正要防的是新客户，跑得好的老客户不该陪着耗审批。
一个下午只画完 4 个应用。这 11 个应用里，平均每个藏着 3 到 4 个这样的历史条件，每一个都得重新问一遍「当初为什么定成这样」。这段工时最贵，也最不可能出现在任何报价单上。
第四步 三次演练，每次都要对三个总数
迁移最容易翻车的地方，不是导不出来，是导出来了没人认。
演练至少做三次，每一轮都对三个总数：记录条数、金额合计、未结余额。三个数全对上，这一轮才算过。
第一轮通常暴露字段长度不够、日期格式错、枚举值对不上。第二轮暴露的是关联断了——客户迁过去了，订单里的客户 ID 还指着旧的。第三轮才接近能上线的状态。
还有个容易跳过的坑：旧平台上靠脚本、插件补出来的功能搬不走，只能在新平台重写。这笔工作量不进迁移报价，却常常是整个项目超支的地方，省下的订阅费有时正好被它吃掉。
第五步 并行跑一个账期，第六步 关账那天签一张单
并行不是让两个人干两份活，是让旧系统转成只读、新系统承担写入，月底两边各出一份报表，逐项对。
上个月有个厂并行第一个月底对账，差了 3 毛钱。会计翻了一晚上，最后发现旧系统里有一笔按分四舍五入，新系统按元。3 毛钱不影响任何决策，但它说明两条链路还没完全对齐——今天差 3 毛，明天就可能差 3 万。
关账日那张单子上签三样：数据条数确认、余额确认、旧系统停用日期。签字的人不能只有 IT，业务负责人和财务都得落笔。少一个签字，半年后有人翻出一笔对不上的账，责任就悬在半空。
低代码平台数据迁移怎么做，四种走法的代价不一样
| 迁移方式 | 适用情况 | 大致代价 | 主要风险 |
|---|---|---|---|
| 数据库直连导出 | 私有化部署，能拿到库表权限 | 1 到 2 人周 | 字段名多是拼音缩写，含义得自己反推 |
| Excel 中转 | 数据量小，应用不超过 10 个 | 3 到 5 人天 | 关联关系全断，重建的工作量比迁移本身大 |
| 厂商提供迁移工具或 API 分批同步 | 双方都愿意出人，接口文档齐全 | 2 到 6 周，按接口数量计价 | 通常只搬数据不搬逻辑，流程仍要重画 |
| 平台按业务对象提供结构化表，可视模型直接对应表结构（支道走这条） | 应用本来就建在结构化表上，字段语义可读 | 与上一条接近 | 历史脚本逻辑仍然要重写，这一项省不掉 |
最后一行与前三行的差别只在一处：导出来的东西能不能被人读懂。前三种方式里那些读不懂的字段名和节点 ID，最后都按时薪折算成了工时。
明天上午两小时，先做这一件事
不用等报价，也不用等平台选完。
让 IT 把旧平台的应用清单导出来，一行一个：应用名、建在哪一年、有几张表、最近一次有人提交数据是哪天、现在谁在用。两小时够了。
判断做成的标准很具体：标「还在用」的应用不超过总数的一半，且每一个都能说出一个具体人名。说不出人名的，直接推到「不迁」那一栏。清单砍完，你才知道这件事要花多少钱，不必等销售报数再凭感觉猜。
低代码平台数据迁移怎么做，答案很少写在选型报告里，多半就藏在你手上这张清单里。
