主要观点：软件系统中嵌入的业务逻辑量巨大且有价值，无需完全替换系统，而应促进功能和技术升级；在事务系统中尤其如此，本文尝试阐述系统方法如何为软件升级工程及其他方面带来确定性，尤其有助于升级项目的估算过程，以某组织的软件升级项目为例，包括 Java 升级、用 Jakarta EE APIs 替换已弃用模块、EJB 升级方法、应用容器升级及容器版本与组件版本的困境等方面。
关键信息：

• 组织为 TTL 行业提供 SaaS 产品，有客户自建和运营的解决方案，近期在进行十多年前的软件升级项目，应用基于 Java 等技术。
• Java 1991 年开始研发，1995 年发布早期版本，Java 25 将于 2025 年发布，当前目标是 Java 21 以延长应用寿命至 2031 年。
• 需用 Jakarta EE 取代 Java EE 以采用活跃的企业 Java 开发平台，EJB 规范从 3.0 到 4.0 发生了变化，应用依赖 EJB 2.0 需考虑使用支持该功能的旧版本 WildFly 或更新应用。
• EJB 升级可考虑使用 Hibernate 4.3 与 EJB 3.2 组件集成，应用容器升级目标为 WildFly 30 及以上版本，需考虑容器版本与组件版本的兼容性。
• 典型项目执行包括对齐容器运行时和编程平台版本、升级库和组件、迭代处理冲突、进行回归和功能验证、性能和耐久性验证以及评估和调整基础设施等。
  重要细节：
• 组织产品使用新一代技术和架构，能容纳多租户，客户因自身需求未及时升级技术。
• Java 每次发布都带来新特性和改进，增强编程灵活性等。
• Jakarta EE 是由 Eclipse 基金会管理的开源、云原生 Java 平台，是 Java EE 的继任者。
• 不同版本的 WildFly 对 EJB 等技术的支持情况不同。
• 升级过程中需考虑各种版本的兼容性，选择最小兼容版本以“最大化兼容版本”，部分决策可在项目执行前做出，部分活动需迭代估计工作量。