客户最早用宜搭解决审批和台账，前三个月效果很好。两年后，表单越来越多，字段没人敢删，权限规则复杂，和财务系统对接也越来越吃力。
快速搭出来的表单，后来承载了核心经营
客户并不是因为宜搭不好用才迁移，而是原来用于“补流程”的应用逐渐装进了销售、订单、合同、项目和回款。字段、权限、自动化和报表互相牵连后，继续往旧表单上叠功能，短期便宜，长期维护风险却越来越高。
问题也不只是页面数量。同一个业务对象往往被拆到多张表里：订单一张、售后一张、发货一张、财务确认又一张。迁移时如果照着旧表单重开发，新平台只会继承原来的数据债。
体检先决定什么留、什么迁、什么归档
项目没有立刻推翻重做，而是先做低代码体检：哪些表单继续留在宜搭，哪些流程需要沉淀为中台能力，哪些历史数据只归档不迁移。最终确定订单、库存、客户、合同四类核心对象进入定制平台。
迁移前先定义核心对象，再决定字段保留、合并或废弃。常查的业务数据进入新平台，低频历史单据保留归档查询。真正要迁移的不是一张张表单，而是已经被企业验证过的业务规则。
这份迁移清单不按旧页面逐张复制，而是分成三类资产：必须保留的核心数据、可以按当前业务重构的流程、只需归档查询的历史表单。核心数据先做字段映射和校验；同一对象分散在多张表时，先合并字段口径再迁移，避免把订单、售后、发货和财务确认之间的旧问题复制到新平台。流程也按当前真实业务重画，不因旧表单曾这样配置就原样照搬。
不停机迁移分三步走
第一步做只读看板，把宜搭数据同步到新平台；第二步让新订单从新平台创建，旧订单继续在宜搭流转；最后再把合同和库存迁过来。一线员工不需要一夜切换，旧业务也不会为了等新系统而停摆。
钉钉入口继续保留，员工还是从熟悉的工作台进入，只是底层数据模型和权限体系换成更可维护的平台。页面好看不是这次迁移的重点，真正的变化是订单、客户、库存和合同不再散落在表单里，可以被报表、权限和接口复用。
迁移成本主要花在数据模型
从宜搭迁到定制平台，难点不是把页面重新画一遍，而是重新梳理对象、字段、权限和历史数据。核心数据要做字段映射和校验，流程按当前真实业务重画；只为临时需求存在的旧表单则直接归档，让新系统变轻。
如果低代码应用已经承载核心收入、库存或合同数据，就应提前规划迁移路线，而不是等性能和权限同时爆雷。
四个信号提示该做架构评估
第一，同一个客户或订单在多张表里维护。第二，改一个字段会影响多个流程和报表，管理员不敢动。第三，权限规则越来越复杂，已经不能用简单角色描述。第四，系统需要对接 ERP、财务、仓储或外部客户门户，接口和性能开始吃紧。
这些信号不等于必须立即全量重构，但至少意味着不能继续无边界地堆表单。先把核心对象和迁移顺序定清楚，才能同时保留低代码的灵活性和核心业务的可维护性。宜搭仍可承担验证期和轻流程；只有已经成熟、需要稳定权限、报表和接口的核心业务才转到底座。迁移越晚，历史数据和流程债越重。
