事实证明，“老旧系统”与其说是关于陈旧的代码，倒不如说更像是一段糟糕的情感关系——只要你开始心系其他选择，它就变成了“老旧系统”。
几年前，我参与过客户某个老旧系统的相关工作，但这并不是用COBOL或汇编语言编写的古老遗迹，而是一个相对较新的C++应用程序，我们就叫它“App1”吧。那么，App1究竟是什么时候变成“老旧系统”的?我客户与它的关系又是在什么时候恶化的呢?
一段平淡乏味的关系
英国政府将老旧IT定义为“过时且通常已被淘汰的技术”，换句话说，就是太老了，但一个应用程序究竟到什么时候才算太老?
我的客户在刚启用App1时，不太可能对它感到厌倦。即使在度过蜜月期之后，也应该有几年时间一切运行顺畅，但不知从什么时候起，这段关系开始走下坡路了。
Linux操作系统创建于1991年，至今已有35年以上的历史，然而它依然是核心的服务器操作系统，谈不上过时。Java创建于1995年，虽然已有31年历史，但依然是具备战略意义的编程语言。App1虽然不是个“婴儿”，但比这两者都要年轻：当时大约有15到20年的历史。有些人可能很享受一段长达20年的关系，而另一些人则早在此时之前就准备好另寻新欢了。
尽管事物会随着时间推移而变得老旧，但对此并没有固定的时间框架。可能是35年，也可能只有一年。过去发生的某些事情让App1变成了老旧系统，但是，究竟是什么呢?
财务问题
澳大利亚政府表示，老旧应用程序可能(除其他因素外)“不再具备成本效益”。与美国政府一样，许多企业将其大部分资金花在了老旧系统上，但它们真的更昂贵吗?
很多人对此深信不疑。银行业咨询公司Digital Bank Expert的一项研究表明，现代化的老旧IT基础设施为银行降低了高达52%的TCO(总拥有成本)，但并非所有人都认同这一点。HPE NonStop专家Justin Simonds就赞同Rocket Software的观点，认为老旧系统并没有人们想象的那么昂贵。
某样东西并不需要真的花更多钱才会变成老旧系统，只需要人们认为它更贵就够了。我负责应用程序的客户意识到了成本问题，但似乎并没有太当回事，然而，对于主机基础设施团队和管理层来说情况却大不相同。多位CIO仅仅因为“感知到的成本高昂”，就制定了摆脱主机的方向。
就像温水煮青蛙一样，我客户的老旧应用程序成本可能并没有在一个特定的时刻突然变成问题，但在某个节点，它们被注意到了，而这段关系中的裂痕也随之扩大。
不受理解
老旧技术人才的匮乏是我的许多客户深感头疼的核心问题，他们抱怨缺乏COBOL和汇编语言程序员，以及了解主机的人员。与许多其他客户一样，尽管有IBM等公司提供的方案，但他们对培训应届毕业生几乎毫无兴趣，仅仅理解技术或编程语言是不够的。老旧系统可能非常复杂，即使是最顶尖的专家也需要时间去搞懂。
随着年长专家的退休且未能补充新人，我的客户失去了对App1的大部分技术储备。为了缓解这个问题，他们依赖一家服务提供商，而该提供商自己在招聘员工方面也遇到了困难。当其中一名员工退休，或者服务提供商难以解决某个问题时，我的客户可能就意识到了这一隐患。
缺乏安全感
2022年，富士通宣布其老旧的GS21主机退役，并将于2035年停止支持。告诉你的伴侣一切都结束了，对这段关系毫无帮助，即使那是在13年之后。如果GS21客户在2022年之前还没把他们的主机视为老旧系统，那么现在他们肯定这么想了。
所有系统都需要一个技术栈，并由某些人(供应商或员工)提供修复和帮助以维持其运行，但正如美国政府问责局(GAO)所强调的，提供支持的一个重大原因在于安全性。像Apache log4j漏洞这样备受瞩目的安全事件，只有得到支持的系统才能获得修复。
GS21主机属于较老的技术，缺少像64位寻址这样的基本操作系统增强功能，因此，GS21用户早在2022年之前就会将其视为老旧系统。难道当某样东西停止改变或创新时，它就变成了老旧系统吗?
App1运行在IBM的旗舰主机IBM Z上，硬件使用不到两年。技术栈的其余部分也类似：最新版本的z/OS操作系统和CICS事务管理器，并定期提供安全补丁和修复。事实上，ITIC在2025年的一项调查发现，在所有平台中，IBM Z主机因安全黑客攻击导致的停机时间最低，安全性根本不是问题。
另一个不是问题的问题是技术栈的停滞，IBM Z主机生态系统持续适应变化，拥有板载AI功能、对Python和Node.js等新语言的支持，以及对Java SpringBoot应用程序的支持，但该栈依然被视为老旧系统，而这就足够了。
最大的问题在于应用程序本身，多年来一直没有重大功能增强，我的客户对利用新IBM主机的各种好功能毫无兴趣。极少的变更意味着支持人员在实施变更方面的经验减少，这逐渐演变成一种支持团队抵制变更的文化。
在同一个厂区，另一个应用程序小组正在对其应用进行重大改造：从老旧的基于文件的存储系统迁移到Db2，尽管如此，这第二个应用程序同样被视为老旧系统，创新并不能保证摆脱“老旧”的标签。
尽管使用了活跃且安全的技术栈，App1本身却处于停滞状态，这并非一朝一夕发生的，而是持续的管理决策导致的后果，最终帮App1摘下了“老旧系统”的标签，但这还不是唯一的问题。
在这段关系中得不到足够的满足
App1的用户界面很旧：陈旧的网页，甚至还有一些类似于依赖UNIX Telnet屏幕的3270屏幕，这在应用程序最初创建时没什么问题，但放在今天却不受欢迎，他们本可以利用IBM主机的一些新技术，但却拿不到预算，老旧的屏幕只能继续沿用。
修改老旧系统总是比新建系统更加困难，随着时间的推移，它的历史包袱越沉重，结构也变得越复杂。任何变更都必须既满足新需求，又要避免破坏现有的任何功能，这种“技术债”会拖慢变更的速度，让无法停下脚步的业务部门大为沮丧。我的客户深有体会，一项变更需要花费数周时间才能部署到生产环境中。老旧系统可能是业务关键型的，人们对App1的停机几乎零容忍。
没有人想要一个带不出门的伴侣，也没有人觉得App1有吸引力，而且这不仅仅是用户界面的问题，我还有另一个客户准备将他们的应用程序从主机迁移走，纯粹是因为市场宣传原因：运行在主机上的旗舰系统不够炫酷。
App1是什么时候变得既难用又丑陋的?也许是当业务部门需要一项无法实现的变更时，亦或是当某位管理者看到陈旧的界面并产生厌恶时。
转变发生的时刻
“老旧系统”并没有官方的定义，也没有任何指标或公式来计算某样东西何时会变成老旧系统，但答案很简单：在我的客户开始寻找更好选择的那一刻起，App1就变成了老旧系统。我不知道那是在什么时候，不太可能有一个突然顿悟的“尤里卡”时刻。
高层管理人员因为感知到的成本而与App1疏远;业务部门则是因为这个毫无吸引力的应用程序抗拒变更。应用程序支持团队也准备另谋高就，几乎没有员工有能力继续支持App1。
我上次与客户交谈时，这段关系还没有真正结束，他们一边在IT应用程序界的“交友软件”上浏览挑选，一边继续用着他们的老旧关系来处理核心业务，他们不喜欢App1的理由，还不足以抵消迁移带来的成本和风险。
对于这段关系来说，现在挽救还不算太晚，我的客户可以重新赋予它活力：培训新员工、投资新技术，但更有可能发生的是，事情最终会达到临界点，我的客户会向右滑(选择新欢)，彻底翻篇。
