サポート終了への対応は、終了日を一覧に書くだけでは進みません。その製品がどの業務を支え、何とつながり、誰が更改を判断するかまで整理すると、必要な準備と着手時期を話し合えます。
この記事では、企業のシステム管理者や運用責任者に向け、サポート終了に備える棚卸しと計画の進め方を紹介します。特定製品の終了日や延長支援の条件を網羅する記事ではありません。
製品名だけでなく、版と支援の条件を確認する
Microsoftは、製品のサポート終了やサービスの終了後、原則として新しい更新や支援が提供されなくなることを説明し、個別製品のライフサイクルを確認するよう案内しています。有償の例外プログラムがある製品もあるため、利用中の条件を個別に確認します。Microsoftのサポート終了の説明
他の提供者も同じ条件とは限りません。製品名、エディション、版、導入形態、利用しているサポートの範囲を合わせて、公式の案内へ照合します。一般的な略称だけで終了時期を決めないようにしましょう。
社内資料へは、確認した日と参照先を残します。終了日の変更や条件の更新があった際に、どの情報から判断したかを追える形にします。
資産一覧を、業務と依存関係へつなげる
まず、対象が実際に使われているかを確認します。そのうえで、同じサーバー上のアプリケーション、連携先、運用ツール、端末など、更新に影響する関係を整理します。
| 項目 | 記録する内容 |
|---|---|
| 対象 | 製品・版・導入先・管理ID |
| 利用業務 | 止まると困る処理、利用部署、稼働する時間帯 |
| 支援条件 | 公式の終了情報、確認日、適用条件 |
| 依存関係 | アプリ、DB、連携先、対応版の制約 |
| 担当 | 業務責任者、技術担当、判断者 |
| 次の判断 | 更新・移行・廃止など、比較する選択肢 |
機器やライセンスの数だけでは、更改の難しさは判断できません。利用頻度が低くても、年次処理などで必要な場合があります。最近アクセスがないという理由だけで廃止対象にせず、業務側の確認を含めて判断してください。
更新・移行・廃止を、同じ目的で比較する
対応には、現在の製品を新しい版へ更新する方法、別の製品やサービスへ移行する方法、業務自体を見直して廃止する方法などが考えられます。どの案でも、必要な業務をどう維持するかを共通の比較軸にします。
更新案では、現在のアプリや連携先が対応するかを確認します。移行案では、機能の置き換えだけでなく、データ、運用、利用者の操作をどう変えるかを整理します。廃止案では、残すべきデータや、別の業務に依存されていないかを確認します。
特定の案が最も安いと、調査前に決めないことも大切です。導入作業、検証、並行運用、教育、終了後の管理まで、比較対象へ含める範囲を揃えます。
仮例：古い帳票システムを更改する
以下は計画の考え方を示す仮例です。実際の当社案件ではありません。
古いOS上で動く帳票システムがあり、OSのサポート終了が近づいているとします。OSだけを更新できるか確認したところ、帳票アプリの対応版と、接続するDBの条件も確認が必要になりました。
この場合は、OSの更新日程だけを引くのではなく、アプリの対応確認、DB接続の検証、帳票内容の照合、利用部署の確認を順に整理します。どれが先に決まらないと次へ進めないかを把握し、調達や停止時間の調整も含めます。
想定していなかった依存関係が出たら、終了日を変えたつもりになるのではなく、残り期間と選択肢を再評価します。暫定対応を検討する場合も、その適用条件と限界を確認し、恒久対応の代わりとして放置しないようにします。
終了日から逆算するのは、作業日だけではない
更改には、判断のための調査、試験、利用部署との調整などが必要です。実施日だけでなく、次の節目を置きましょう。
- 対象と依存関係の確認を終える時点。
- 選択肢を比較し、方針を決める時点。
- 必要な検証と業務側の確認を終える時点。
- 移行や切替を行い、旧環境の扱いを確定する時点。
期限が厳しい場合は、遅れている事実と不足情報を早く共有します。日付だけを後ろへ動かして、リスクが解消したとは扱わないでください。
切替時の確認はクラウド移行の切替計画、費用の前提整理はクラウド費用の見積もりを参考にできます。対象一覧と残る判断をまとめることで、インフラ・クラウド支援への相談も具体化できます。