数字化转型与遗留系统现代化：优先改变什么，以及AI如何助力

本指南面向中型企业的业主、首席运营官、首席技术官及IT经理——这些企业的系统往往是随业务发展自然累积而来，而非与业务同步规划：老旧的商店系统、靠电子表格勉强支撑的ERP、无人能完全理解的集成接口。本指南阐述如何对工作进行排序，使每一步都能为下一步提供资金；如何在重建、重构、迁移平台等选项之间做出选择；如何在不停业的情况下对在线系统进行现代化改造；以及AI在哪些环节能加速工作或延伸成果。最后以两个电商案例和一份可供参考的风险登记表收尾。

本指南目录

• 顺序比技术更重要
• 变革的三个层次
• 中型企业的排序模型
• 重建、重构还是迁移平台：如何决策
• 指向各路线的信号
• 分步现代化在线系统
• 数据、集成与搜索可见性
• 两个电商案例
• AI在现代化项目中的定位
• 时间线及影响因素
• 现代化风险登记表
• 常见错误
• 本指南的局限性
• 常见问题
• 本指南的制作方式
• 下一步

顺序比技术更重要

数字化转型失败，往往不是因为选错了技术，而是因为顺序错了。三种模式反复出现：

• 先上平台，再改流程。购买或搭建了新系统，却将旧有的变通做法原样复制进去。企业为新平台付出代价，却保留了旧有成本。
• 全面铺开。大爆炸式替换在同一时间触及每个团队、每个集成和每位客户。一旦延期，整个业务都要等待。
• 改造无关紧要的系统。将精力放在技术最陈旧的系统上，而非那些阻碍营收、服务或降本的系统。

中型企业几乎没有多余的预算或管理精力来从这些错误中恢复。正确的做法是：先明确业务必须在哪些方面有所改变，再只对阻碍这些改变的系统进行调整，且调整顺序要保证每一步单独来看都有价值。

变革的三个层次

大多数转型预算花在平台层，而大多数价值却在流程层和系统层释放。规划时应自上而下推进，只有当平台面临风险时——版本停止支持、存在安全漏洞或供应商退出迫使调整时间表——才自下而上推进。

中型企业的排序模型

一个切实可行的排序方案包含五个阶段。每个阶段结束时都有业务可用的成果，因此即便项目暂停，也不会留下半途而废的工作。

Netbase JSC 通过六步交付生命周期来执行此类项目，从发现与架构规划，到敏捷执行、上线及持续支持。上述第1、2阶段包含在发现阶段；现代化工作本身在敏捷迭代中推进，每周进行评审，以成果为里程碑，以英语为工作语言远程交付，基地位于河内，安全设计融入每个模块而非在最后测试。

如需将上述阶段转化为中型企业路线图的规划模板，请参阅我们的数字化转型路线图指南。如需从基线出发形成可交付的计划，数字化转型咨询可将基线转化为可执行方案。关于企业跳过遗留阶段的情况，请参阅新兴市场的数字化与AI转型。关于软件项目在第2阶段开始前需要多少流程重新设计，请参阅我们的软件实施前的业务流程转型清单。

重建、重构还是迁移平台：如何决策

「重建还是重构」通常被视为二选一。实际上选项更多，而且最经济的好答案往往根本不涉及代码改动。AWS规范性指导列出了七种迁移策略，即「7个R」：退役（retire）、保留（retain）、重新托管（rehost）、重新定位（relocate）、重新采购（repurchase）、迁移平台（replatform）和重构（refactor/re-architect）。对于中型企业的应用程序现代化，其中五种最为重要，加上完整重建。

AWS指出，重构是最复杂、成本最高的策略，并建议大型迁移项目先完成迁移再做现代化。同样的逻辑适用于中型企业：将「迁移至受支持的基础平台」与「重新设计应用程序」分开处理，除非二者必须同步进行。

五个问题可帮助解决大多数决策：

1. 系统是否仍适合目标流程？若是，选择迁移平台或保留。若否，选择重新采购、重构或重建。
2. 平台是否受支持且安全？若否，时间表已由外部决定；先进行迁移平台。
3. 该功能是否具有业务差异化价值？若否，打包产品通常拥有更低的总拥有成本。
4. 变更能否分步推进？若能，优先选择渐进式现代化，而非一次性切换。
5. 谁了解旧系统所执行的规则？若无人了解，在任何重建前先预算发现阶段。

指向各路线的信号

评估结果很少给出唯一明确的答案，但某些发现会强烈指向某一方向。

混合发现是正常的：许多项目先迁移平台以恢复安全支持，再对变更最频繁的部分进行重构。遗留系统评估清单列出了使用此表前应收集的证据。

数据、集成与搜索可见性

以下三个方面是现代化项目中最常出现意外的领域。在选择方案前，请对其进行盘点。

对于在线商店，搜索可见性和订单连续性是最常决定迁移平台成败的两项风险。我们的定制电商平台指南深入探讨了商店的迁移平台决策与迁移规划。

两个电商案例

迁移平台：Netztech。Netztech的商店运行在Magento 1上，需要迁移至Magento 2而不从头开始。Netbase JSC将其迁移至Magento 2 Commerce。迁移历时35个工作日，包括11个模块的扩展迁移，涵盖安装、配置、定制和数据迁移。本项目未发布性能指标；它展示了在业务模式保持不变的情况下，迁移平台的范围和时间安排。查看Netztech迁移记录。

无需迁移平台的现代化：Rebelo AG。Rebelo AG是一家成立于1983年的葡萄牙公司，无需更换平台。其客户无法在成品上预览自己的设计，因此在下单前犹豫不决。Netbase JSC为其现有在线商店添加了3D商品预览功能。Rebelo AG报告称，第一年营收增长39%，互动率提升98%，个性化细分转化率提升53%，生产力提升25%。这一案例的启示是：优先解决流程阻碍项；平台决策可等到平台本身成为阻碍时再做。查看Rebelo AG案例。

两个案例均来自在线零售与电商领域，在这一领域，切换失败的代价以丢失的订单来衡量。了解 Netbase JSC 如何应对店面、市场平台和订单运营，请参阅零售与电商；当商店正在发展为多供应商模式时，电商市场平台解决方案展示了平台选项，欧盟时尚市场平台案例则展示了此类迁移的实际案例。

时间线及影响因素

Netbase JSC 电商构建的典型范围：小型商店为1至3个月，中型商店为4至6个月，企业级平台为6至12个月或更长。这些是典型范围，而非报价。定制化程度低的迁移平台可能更快，如Netztech的时间安排所示；集成较多的重建项目则处于较高端。

影响现代化时间线的因素：

• 扩展、自定义模块和集成的数量；
• 数据量与数据质量，以及需迁移的历史数据范围；
• 依赖旧系统的URL、报表和下游消费者数量；
• 业务可接受切换期间变更冻结的时长；
• 业务负责人做出流程决策的速度。

现代化风险登记表

在每次阶段变更时审查登记表。没有责任方的风险依然是风险，只是无人管理而已。

常见错误

• 购买平台来解决流程问题。新系统继承了旧有的变通做法。
• 对本可分步推进的系统进行大爆炸式切换。一个日期承担了所有风险。
• 重构缺乏业务目标。代码更整洁但没有改变任何指标，难以获得二次投入。
• 未经发现阶段即开始重建。旧系统中未成文的规则以缺陷形式重新出现。
• 忽视搜索可见性。排名下降的商店会失去新平台本应带来增长的营收。
• 在上线时结束项目。培训、推广和优化才是赢得用户采纳的阶段。

本指南的局限性

本指南是基于 Netbase JSC 交付经验的实践性指导，并非原创研究。迁移策略来源于AWS针对云迁移编写的指南，此处将其应用于应用程序现代化的一般场景；「绞杀榕」模式是通用架构方法。时间线是取决于项目范围的典型范围。除4over4功能外，所描述的AI用途属于能力，而非可衡量的结果。Netztech记录仅描述范围和时间安排，Rebelo AG的结果由客户针对该项目进行报告，结果取决于其基线和市场情况。

本指南的制作方式

Netbase JSC 编辑团队根据 Netbase JSC 已发布的交付生命周期、迁移和案例研究页面，以及AWS和Martin Fowler的公开指导编写了本指南。David（首席执行官）审核了所有 Netbase JSC 相关事实。外部来源注明了访问日期。起草过程使用了AI辅助（Claude）。本指南旨在帮助中型企业按照每一步都能为下一步提供资金的顺序推进现代化改造。

下一步

请告知您当前的系统情况、最棘手的流程以及任何平台截止期限，我们将预约解决方案评审，对阻碍项进行排序并提出第一步现代化建议。您也可以查看相关服务或浏览更多Netbase JSC 洞察。

相关服务与解决方案