这些企业舍不得换掉用了十年的老系统，一方面是情怀，那更多的可能是其他原因，下面我们从多方面的原因来探究性的聊聊：
近六七年，在B端IT领域，各种新概念、模式层出不穷，要是软件厂商做的东西不和这些新概念沾点边，那就被认为跟不上时代，连互联网公司在这新概念前也显得传统。
低代码/零代码：
它的概念是这样诞生的，由于企业个性化业务强，变化频繁，原有信息化系统跟不上新的业务场景，所以需要自定义变更系统从而来适配业务，具备敏捷能力；
通过对市面上一些相关领域产品分析，能自定义实现表单、流程、简单报表等业务，所有的业务处理停留于表层，就比如企业管理软件ERP，应用复杂，耦合度高，要做账务处理、成本核算、财务报表等，靠单纯的低代码/零代码概念难以发挥价值；
数据/业务中台：
“大中台，小前台”，是阿里巴巴在2015年提出的概念，通过抽象剥离相似业务，沉淀核心能力到中台，前端各应用进行复用，减少重复造轮子的现象，这样就能支撑前台快速试错、快速创新，既然是阿里巴巴提出，并不等于其他企业都是阿里巴巴、都能发挥同等的价值；
技术在发展进步，无可厚非，2008年以前的ERP，大部分是C/S的，基本采用C#或者VB.NET语言开发，后来的ERP偏向Web，用Java Web的居多，目前也有开源的ERP，部分是Python Web开发，当然，也是有用PHP开发的，就拿ERP软件举例：
SAP：从一开始的C，后主要为“ABAP/4”语言；Oracle Peoplesoft：从C++到Java；Oracle E-Business Suite：Java；
在架构层面也在不断的迭代升级，从单体架构到微服务等，负载能力确实在不断提升：
单体架构：典型的三级架构，前端(Web/手机端)+中间业务逻辑层+数据库层。
分布式架构：中间层分布式+数据库分布式，是单体架构的并发扩展，将一个大的系统划分为多个业务模块，业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。
微服务架构：主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上，某一应用故障发生不会影响到其他应用，单应用的负载也不会影响到其他应用。
数据库选型上，也有了更多的选择，主要就有以下三种：
MySQL：瑞典MYSQLAB推出，关系型数据库，开源免费，适用于WEB网站、日志管理、数据仓库和嵌入式系统等小型系统；
SQLServer：微软Microsoft推出，关系型数据库，可视化、安全性与稳定性较好，适用于企业级海量数据存储查询；
Oracle：美国甲骨文公司推出，关系型数据库，跨平台，安全稳定，结构复杂，对管理员要求高，常用于金融、电信领域；
不可否定，不管是开发语言、技术架构、数据库技术的进步提升了应用的可靠性、稳定性、扩展性，但是功能应用仿佛还是十几年前的那些老功能，对于广大用户关心的可能是业务覆盖能力，而底层的技术更迭没有起到决定性作用。
竞争变大：
目前各行各业竞争对手越来越多，再加上贸易战的冲击，很多企业家都是在夹缝中求生存，据统计，每天注册公司的人，超过1.2万家，做系统替换是一个潜在风险，面对竞争不敢大步迈进。
业务变窄：
为了让企业活得久一点，不敢去尝试新型业务，不断瘦身，最终业务越来越窄，只剩下企业最擅长、获利快的业务，根本来不及考虑是数字化转型还是信息化替代的事情。
利润变薄：
在竞争变大、业务变窄的背景下，价格战是存活的最后招数，可以说是杀敌一千，自损八百，面临的后果就是拿了客户、赔了成本，更没有精力投入大价钱去做系统更换。
保持稳定：
原有的业务做了多年，适配的系统也是用了多年，已经形成了固定的管理思维方式，为了保持稳定，没必要去做无价值的软件替换。
作为多年经营的企业，历史数据在一定程度上发挥着重要价值，替换系统意味着历史数据丢弃，即使能够进行业务数据转移，也不是一件易事，由于新老系统数据结构的差异，数据清洗工作异常繁杂。
