过去几年，企业数字化转型的投入大多集中在前台：官网、App、小程序、营销中台不断迭代，用户体验肉眼可见地改善。可一旦项目触及订单、结算、库存、生产等核心环节，节奏往往骤然放缓。真正拖住转型步伐的，常常是那些已运行十年甚至二十年的遗留系统。
瓶颈不在前台，而在后台
遗留系统的麻烦并不只是“老旧”。它往往同时具备几个特征：数据结构建立在当年的业务假设之上，字段含义靠口口相传；接口以批处理为主，难以支撑实时并发与对外开放；改动一处牵动全身，回归测试成本高，业务需求被迫排队；熟悉代码的工程师逐渐退休或转岗，知识随人流失。
于是出现一种常见错位：前台系统越来越轻，后台系统越来越沉。任何新业务都要围绕老系统的能力上限来设计，转型就变成了在旧地基上加盖新楼层。
现代化不等于推倒重来
直接重写核心系统，历史上失败案例并不少见。业务规则散落在代码、脚本和人工操作之中，重写意味着先把隐性规则显性化，工程量常被严重低估。更稳妥的做法是“绞杀者模式”：把老系统当作被包裹的对象，用接口层先封住其能力，再按领域边界逐个替换内部模块，最终让旧系统自然退出。
常见的技术路径包括：
- 接口封装，把老系统能力包装为标准接口，让前台先能灵活调用；
- 按业务领域拆分，围绕订单、库存、结算等边界逐个抽出独立服务；
- 事件驱动改造，用消息机制解耦，减少同步调用带来的连锁故障；
- 数据先行，先统一主数据与指标口径，再谈系统替换。
顺序比技术选型更重要。先接口、后服务、再数据，通常比一上来就重写数据库可控得多。
并行运行期最考验治理
新旧系统并行运行，是现代化过程中风险最集中的阶段。同一笔业务可能被两边同时处理，数据一致性、幂等设计、补偿机制都需要提前设计；灰度切换要按业务线或区域逐步放量，并保留可回滚方案；监控与日志要能同时覆盖两套系统，否则故障定位会变得异常困难。这一阶段真正需要的，是清晰的切换清单、明确的责任人和可量化的验收标准。
用度量把现代化变成持续能力
核心系统现代化很难靠一次项目完成，更适合作为持续能力来经营。企业可以跟踪几类指标：需求从提出到上线的交付周期、接口复用率、故障恢复时间，以及老系统上新增改动所占的比例。当新增改动越来越多落在新架构上、老系统只做必要维护时，现代化才算真正走上轨道。
归根结底，数字化转型的深度取决于后台的弹性。把遗留系统当作需要长期经营的资产，而非待清理的包袱，转型才有机会从前台的热闹，走向业务的实质改变。