我们已经近十年没有升级我们的 RDBMS 或服务器操作系统。另一个关键任务软件包已经有将近 20 年的历史了，并且在那段时间的大部分时间里都没有得到其供应商的支持。我们管理层中的一些人似乎认为这是一件好事——我们通过不购买升级而节省了大量资金！现在一个关键的软件需要升级，但新版本将不支持十年前的东西。现在，我们中的一些人正在脱发，试图弄清楚如何以最少的停机时间立即升级所有内容。
为了在未来避免这种情况，我们中的一些人正在考虑创建一个 IT 战略计划文件（这将适合组织的战略计划，充实与 IT 相关的更大文档中的项目......也许使 IT 文档成为一种战术计划？）希望我们能够将其作为该机构总体战略计划的一部分。我自愿尝试组装“软件生命周期管理”（或类似的东西）部分来解决上面提到的问题（黄铜大头针可能在战略计划的单独文件中）。几乎所有软件供应商都会发布其产品的生命周期和弃用计划，考虑到该信息以及我们组织的需求，很容易确定每个软件的“最佳位置”。棘手的部分（无论如何对我来说）是将每个部分的计划放在一起变得更有凝聚力。
我如何记录桌面客户端 A、B、C... 依赖于桌面 OS X 和 RDBMS Y，而后者又依赖于服务器 OS Z，然后我们如何将它们保持在“最佳位置”？那里肯定有书，但我所有的谷歌搜索只让我了解升级单个软件的策略，而不是确定何时实施这些策略的策略。