我们已经有近十年没有升级 RDBMS 或服务器操作系统了。另一个关键任务软件包已有近二十年历史，而且大部分时间都没有得到供应商的支持。我们的一些管理层似乎认为这是一件好事——通过不购买升级，我们节省了大量资金！现在一个关键的软件需要升级，但新版本不支持十年前的东西。现在我们中的一些人正在努力弄清楚如何一次性升级所有内容，同时将停机时间降到最低。
为了避免将来出现这种情况，我们中的一些人正在考虑创建一份 IT 战略计划文档（它将融入组织的战略计划，充实与 IT 相关的大型文档中的项目……也许这会使 IT 文档成为战术上的计划？），希望我们能将其作为机构整体战略计划的一部分采纳。我自愿尝试整理“软件生命周期管理”（或类似内容）部分来解决上述问题（具体细节可能与战略计划分开）。几乎所有软件供应商都会发布其产品的生命周期和弃用计划，考虑到这些信息以及我们组织的需求，很容易确定每个软件的“最佳点”。棘手的部分（至少对我来说）是将每个部分的计划整合成更具凝聚力的计划。
我如何记录桌面客户端 A、B、C... 依赖于桌面 OS X 和 RDBMS Y，而后者又依赖于服务器 OS Z，然后我们怎样才能让它们都处于“最佳状态”？肯定有相关书籍，但我在谷歌上搜索到的所有信息都只是关于升级单个软件的策略，而不是确定何时实施这些策略的策略。
答案1
看起来您正在尝试同时解决许多问题（而且这看起来不是一个好主意）。
据我所知：
- 过时的操作系统和应用程序
- 没有长期战略
- 记录基础设施的问题
- 迫切需要升级关键基础设施
升级“关键软件”
您的基础设施由于某人的决定而过时是很容易理解的。在过去的某个时候，这似乎是一个好主意。这归结为 Michael Hampton 在评论中写道：对于管理层来说，您谈论的是利弊（风险）。因此，如果管理层愿意承担风险，那么可以（无论您个人如何看待），从现在起这是他们的责任。但是 IT 人员必须告诉他们风险是什么。
因此，我首先要考虑的是：管理人员是否知道过时软件的风险？他们被告知了吗？
老实说，我觉得你可能不会发现它有什么用处，所以我不会花太多时间在它上面。它只是能帮到你的东西，就像“我们在过去五年里一直在告诉你”一样。
我会简单地分析执行升级的真正意义。准备一份简单的电子表格，列出活动和它们需要多长时间（如果您不知道，请给出最佳猜测，并明确强调您不确定）。但请记住，这个“升级任务”没有明确规定，不可能以固定时间/固定价格的方式完成。
制作这样的列表也有助于您深入了解整个问题。下一步是创建风险日志和所需资源列表。
最后，您应该有活动清单、风险清单、所需材料/人员清单。 总之，不要将升级视为日常问题，而要将其视为一个项目。 这将使您至少能够对公司的急切需求有一定的控制权。
如果您在分析需要完成哪些活动时遇到问题，您可以尝试一些思维导图（我最喜欢的软件是 xMind），然后将其转换为更正式的文档。
请注意，当您有几种升级方案时，您应该向您的经理提供一份可能的解决方案的说明（如果有更多），用几句话总结，包括成本、结果和风险；最好提到您推荐的选项及其原因。因为最终的选择权在他们手中——毕竟他们是经理。
也许在这种特殊情况下：提到升级可能根本是不可能的。
没有长期战略
现在制定战略计划对你没有帮助。如果这是 IT 部门内部酝酿的文件，那根本帮不了你。战略计划需要与业务需求挂钩。
业务需求示例：两年后，我们将在中国和澳大利亚开设新办事处。
衍生的 IT 任务：准备好让新员工适应他们的工作岗位，在国外办事处创建基础设施，为新员工提供培训（可能使用他们的母语），提供从这些办事处到中央的安全连接......
如果一切顺利，几个月后你也许就能制定出一个战略？所以大约半年后一切就都达成一致了？
维护和记录您的基础设施
这是过去的遗产，现在你必须改变一些东西。确定优先次序。列出你想要/现在必须做的事情，以使大多数事情都与时俱进。选择哪些可以等待，制定一个粗略的路线图。（如果你有路线图，它应该是你的 IT 战略的一部分。）
如果您要更新进展顺利的事情，请将其作为日常事务处理。如果您要处理的事情可能会出错（在花费的时间、分配的人员等方面“很大”），请将其作为项目处理。
有一些工具可以帮助您处理文档和服务依赖关系 - CMDB（例如 iTop）。但要让它工作起来可能需要一些时间，而且您仍然需要一些文档工具。最好的办法是为文档设置一个 wiki，从现在开始每个人都可以开始记录/做笔记。您可以在半小时内设置一个 wiki，所以这是一种非常有效的入门方式。
个人备注：升级这么老的操作系统会非常麻烦，更不用说（可能不好/缺失的）文档了。重新安装服务器、迁移应用程序并从一开始就记录所有内容不是更容易吗？