商用ソフトウェアをアップグレードするための戦略を文書化する方法は？
RDBMSまたはサーバーOSを10年近くアップグレードしていません。もう1つのミッションクリティカルなソフトウェアパッケージは、20年近く前のものであり、そのベンダーの多くはその間サポートしていません。経営陣の中には、これは良いことだと考える人もいるようです。アップグレードを購入しないことで、莫大な費用を節約できました。現在、重要なソフトウェアはアップグレードが必要ですが、新しいバージョンは10年前のものをサポートしません。今、私たちの一握りは、最小限のダウンタイムで一度にすべてをアップグレードする方法を見つけようとして頭を失っています。
将来これを回避するために、IT戦略計画文書（組織の戦略計画に適合し、ITに関連するより大きなドキュメントの項目を具体化する）の作成を検討している人がいます... ITドキュメントを戦術計画？）にし、代理店の全体的な戦略の一部として採用できることを期待しています。予定。私は、上記の問題に対処するために、「ソフトウェアライフサイクル管理」（またはそのようなもの）セクションを組み立てることを志願しました（戦略計画とは別のドキュメントにある可能性が高い真鍮の鋲で）。ほぼすべてのソフトウェアベンダーが自社製品のライフサイクルと非推奨計画を公開しており、その情報と組織のニーズを考慮して、各ソフトウェアの「スイートスポット」を簡単に決定できます。トリッキーな部分（とにかく私にとって）は、各ピースの計画をよりまとまりのあるものにまとめることです。
デスクトップクライアントA、B、C ...がデスクトップOSXとRDBMSYに依存していることを文書化するにはどうすればよいですか。RDBMSYはサーバーOSZに依存しています。次に、これらすべてを「スイートスポット」に維持する方法を説明します。本はそこにあるに違いありませんが、私のグーグルのおかげで、ソフトウェアをアップグレードする戦術については、それらの戦術をいつ実装するかを決定するための戦略ではなく、ただ物事に導いただけです。
あなたは一度に多くの問題を解決しようとしているように見えます（そしてそれは良い考えのようには見えません）。
私が読んだものから：
- 古いOSとアプリケーション
- 長期的な戦略はありません
- インフラストラクチャの文書化に関する問題
- 重要なインフラストラクチャをアップグレードする緊急の必要性
「重要なソフトウェア」のアップグレード
誰かの決定によりインフラストラクチャが古くなっていることは簡単に理解できます。過去のある時点で、それはおそらく良い考えのように思えました。これは、マイケル・ハンプトンがコメントで書いたものに要約されます：管理のために、あなたは長所と短所（リスク）について話している。したがって、経営陣がリスクを負うことをいとわないのであれば、大丈夫です（あなたが個人的にそれについて考えていることは何でも）、そしてそれは今後の彼らの責任です。 しかし、IT担当者の誰かが、リスクが何であるかを彼らに伝えなければなりません。
それで、私が最初に探すことは次のとおりです。マネージャは古いソフトウェアのリスクについて知っていましたか？彼らは言われましたか？
正直なところ、役に立たないかもしれないと思うので、あまり時間をかけないようにしています。それは、「過去5年間、あなたに言っていた」という線に沿ってあなたを助けることができるものにすぎません。
そのアップグレードを実行することの実際の意味を分析するだけです。活動とそれらにかかる時間を含む簡単なスプレッドシートを準備します（わからない場合は、推測をし、はっきりとわからないことを明確に強調してください）。ただし、この「アップグレードタスク」は適切に指定されていないため、fix-time/fix-priceとして実行することはできません。
このようなリストを作成すると、問題全体をドリルダウンするのにも役立ちます。次に、リスクログと必要なリソースのリストを作成します。
最後に、活動のリスト、リスクのリスト、必要な資料/人のリストが必要です。 一言で言えば、アップグレードを日常の問題として扱うのではなく、プロジェクトとして扱ってください。これにより、会社の緊急のニーズを少なくともある程度制御できるようになります。
実行する必要があるアクティビティの分析に問題がある場合は、マインドマップ（私のお気に入りのswはxMindです）を試してから、それをより正式なドキュメントに変換できます。
アップグレードの方法についていくつかのオプションがある場合は、考えられる解決策（存在する場合）を、コスト、結果、リスクを含めて数文に要約して上司に報告する必要があります。理想的には、推奨するオプションとその理由を説明します。最終的な選択は彼らが行うことなので、結局のところ、彼らはマネージャーです。
たぶんこの特定のケースでは：アップグレードがまったく不可能かもしれないことに言及してください。
長期戦略なし
戦略的計画を作成することは今あなたを助けません。 IT部門内で作成されたドキュメントの場合は、まったく役に立ちません。戦略的計画は、ビジネスニーズに結び付ける必要があるものです。
ビジネスニーズの例：2年以内に、中国とオーストラリアに新しいオフィスを開設する予定です。
派生したITタスク：新入社員に最悪の事態をもたらす準備をし、外国のオフィスにインフラストラクチャを作成し、新入社員にトレーニングを提供し（おそらく母国語を使用）、それらのオフィスから中央への安全な接続を提供します...
うまくいけば、戦略を立てることができるかもしれません...数か月で？それで、すべてが合意されるまでの約半年？
インフラストラクチャの保守と文書化
これは過去からの遺産であり、今、あなたは物事を変える必要があります。優先順位を付けます。ほとんどのことを最新の状態にするために、今したい/したいことのリストを作成します。どちらを待つことができるかを選択し、大まかなロードマップを作成します。 （このロードマップは、IT戦略がある場合は、その一部である必要があります。）
うまくいったものを更新する場合は、日常業務として扱ってください。悪くなる可能性のあるもの（費やした時間や割り当てられた人員などの点で「大きい」）を処理している場合は、それをプロジェクトとして処理します。
ドキュメントとサービスの依存関係を支援するツール-CMDB（iTopなど）があります。ただし、動作させるには時間がかかる場合があり、それでもドキュメントツールが必要です。最良のアイデアは、誰もがこれからドキュメント化/メモの作成を開始できるドキュメント用のwikiを設定することです。 Wikiは30分でセットアップできるので、始めるのに非常に効果的な方法です。
個人的なメモ：古いOSをアップグレードすると、（おそらく悪い/欠落している）ドキュメントについては言及せずに、巨大なPITAになります。サーバーを新たにインストールし、アプリを移行し、最初からすべてを文書化する方が簡単ではありませんか？