本文定位：匿名客户案例。它不是产品宣传稿，而是把一个常见的企业数字化问题拆成“背景—症状—方案—结果—经验”，方便你对照自己的情况判断。
一、背景：问题不是突然出现的
客户最早用宜搭解决审批和台账，前三个月效果很好。但两年后，表单越来越多，字段没人敢删，权限规则复杂，和财务系统对接也越来越吃力。
二、关键症状：真正卡住业务的地方
我们没有建议客户立刻推翻重做，而是先做低代码体检：哪些表单继续留在宜搭，哪些流程需要沉淀为中台能力，哪些历史数据只归档不迁移。最后确定订单、库存、客户、合同四类核心对象迁到定制平台。
三、落地/救火路径：先收口，再扩展
迁移分三步：先做只读看板，把宜搭数据同步到新平台；再让新订单从新平台创建，旧订单继续在宜搭流转；最后把合同和库存也迁过来。这样一线不需要一夜切换。
四、结果：能被管理动作验证的变化
这个过程最大的收益不是页面变好看，而是数据模型稳定了。订单、客户、库存和合同不再是散落表单，而是可以被报表、权限和接口复用的业务对象。
五、给同行的建议：别先追求大而全
低代码不是错，错的是把低代码当无限扩展的平台。合适的做法是让它承担验证和轻流程，核心业务成熟后再迁到可维护的中台。
六、可直接照抄的检查清单
| 检查项 | 要问的问题 | 不合格信号 |
|---|---|---|
| 业务目标 | 这次项目到底要让哪个指标变好？ | 只说“提升效率”，没有具体场景 |
| 数据来源 | 关键数据现在在哪里、谁负责维护？ | 数据散在个人 Excel 和聊天记录里 |
| 责任闭环 | 异常出现后谁处理、多久复查？ | 只有提醒，没有责任人和复查机制 |
| 上线范围 | 第一阶段哪些必须做、哪些先不做？ | 一期就想覆盖所有部门 |
| 管理承接 | 上线后在哪个会议、哪个岗位使用？ | 系统上线后没人固定看 |
七、迁移时最容易被低估的成本
从宜搭迁到定制平台，难点不只是重新开发页面，而是重新梳理数据模型和历史数据。很多企业过去两年为了快，给同一个业务对象建了多张表：订单一张、售后一张、发货一张、财务确认又一张。迁移时如果只是照搬表单，新平台也会继承旧问题。
比较稳的方式是先定义核心对象，再决定哪些字段保留、合并或废弃。历史数据不一定全部迁移，常查的业务数据进入新平台，低频历史单据可以归档查询。这样既能降低迁移风险，也能避免业务一夜切换失败。真正要迁移的不是“表单”，而是企业已经验证过的业务规则。
补充一个判断标准：如果一个低代码应用已经开始承载核心收入、库存或合同数据，就应该提前规划迁移路线，而不是等到性能和权限一起爆雷。
八、迁移不是推翻宜搭，而是给核心业务换底座
这个案例里，客户并不是因为宜搭不好用才迁移，而是原来快速搭出来的应用已经从“补流程”变成“承载核心经营”。销售、订单、合同、项目、回款都在里面，但字段、权限、自动化和报表越来越难维护。继续在原有表单上堆功能，短期便宜，长期风险越来越高。
迁移时我们没有一次性重写所有功能，而是先识别三类资产：必须保留的核心数据、可以重构的流程、可以归档的历史表单。核心数据先做字段映射和校验，流程按当前真实业务重新画，而不是照搬旧表单。很多旧表单其实只是历史临时需求，迁移时直接归档，反而让系统变轻。
钉钉入口仍然保留，员工还是从熟悉的工作台进入，只是底层数据模型和权限体系换成了更可维护的平台。这样迁移对一线影响较小，管理层也能获得更稳定的报表和接口能力。
九、什么时候该从低代码迁到定制平台
可以看四个信号。第一，核心对象被复制多份，同一个客户或订单在多张表里维护。第二，改一个字段会影响多个流程和报表，管理员不敢动。第三，权限规则越来越复杂，已经不能用简单角色描述。第四，系统需要对接 ERP、财务、仓储或外部客户门户，低代码接口和性能开始吃紧。
出现这些信号时，不代表马上全量重构，但至少要停止继续堆表单，先做架构评估。迁移越晚，历史数据和流程债越重。
十、落地前可以先问自己的五个问题
第一，当前最痛的业务动作是什么，是销售漏跟、库存不准、项目亏损、数据口径不一，还是系统没人用？如果一句话说不清，说明项目目标还需要继续收敛。第二，这个动作今天的数据在哪里，是系统里、Excel 里、微信群里，还是某个人脑子里？数据越分散，第一阶段越要小。第三，谁是这个数据的负责人，谁有权决定字段口径和流程变化？没有负责人，系统上线后也会变成无人维护的表。
第四，异常出现后谁处理，处理结果回写到哪里？很多数字化项目只做到“发现问题”，没有做到“问题被处理并复查”，价值会卡在最后一公里。第五，老板或管理层准备在哪个会议里固定使用这套系统？如果上线后没有会议承接，大家很快会回到原来的汇报方式。
这五个问题的答案，比功能清单更重要。功能清单决定开发什么，五个问题决定系统上线后有没有人用、有没有人维护、有没有管理动作跟上。
十一、适合先做小诊断的企业画像
如果你的企业已经有一些系统，但数据分散、口径不一、老板看数还要等人导表，适合先做诊断；如果你的企业还主要靠 Excel、钉钉群和人工审批，也适合先做诊断，因为这时最重要的是确认第一阶段到底该系统化哪一段。
不适合一上来做大项目的情况也很明确：目标太泛，只说“全面数字化”；内部没人能拍板；历史数据没人愿意清；业务部门只想让 IT 自己解决；老板希望一次上线解决所有问题。遇到这些情况，先做 1 到 2 周的小范围梳理，反而比直接开发更省钱。
开沿通常会把诊断结果拆成三张图：业务流程图、数据流转图、一期范围图。三张图对齐后，再决定用标准 SaaS、低代码、钉钉二开、系统集成还是定制开发。这样做慢在前面，快在后面，也能减少上线后推倒重来的概率。
补充一点：第一阶段还要提前约定复盘节奏。上线后的前四周，建议每周固定看一次使用数据、异常清单和业务反馈，把必须改的小问题快速收掉，把“以后再说”的需求放进二期池。这样既能保护一期范围，也能让业务团队看到系统是在持续服务他们，而不是上线后就没人管。
十二、开沿的建议
如果你看到这里，最该做的不是立刻问“做一套多少钱”，而是先把当前流程画出来：数据从哪里来，谁加工，谁决策，谁执行，结果回写到哪里。只要这条链路不清楚，系统越复杂，后期越难维护。
开沿更愿意先做小范围诊断：选一个高频场景，确认数据和责任是否能闭环，再判断适合低代码、标准 SaaS、二开还是定制。这样预算更可控，也更容易让团队真正用起来。
