先代の代から動くWindows Serverのサポート終了（EOL）対応

先代の代から動くWindows Serverのサポート終了（EOL）対応

社長室の奥、あるいは倉庫の一角に置かれたサーバーラック。埃をかぶった箱の中で、先代の時代から一度も再起動していないWindows Serverが今日も静かに動いている——そんな会社は、実はめずらしくありません。「動いているから大丈夫」「詳しいのは辞めた前任者だけ」「営業がメインだから機械のことはよくわからない」。承継したばかりの二代目・三代目社長がぶつかる壁のひとつが、まさにこの「先代が入れたサーバーのサポート終了（EOL）」問題です。

結論から言います。Windows Serverには明確な「延長サポート終了日」があり、その日を過ぎるとセキュリティ更新プログラムの提供が止まります。放置すれば、ランサムウェア被害や取引先からの信用失墜に直結するリスクを抱えたまま経営を続けることになります。対応の順序は、①今動いているサーバーのOSバージョンと役割を確認する、②サポート終了日を調べる、③移行かESU（延長セキュリティ更新プログラム）かを判断する、④予算と体制を確保して実行する——この4段階です。この記事では、非IT出身の社長でも迷わず動けるよう、判断の手順と相談先の選び方を具体的に解説します。

こんな状態の人に向けて書いています

• 先代の代からある社内サーバーが「何のOSで、いつまでサポートされるのか」を答えられない
• 「サーバーの中身は前の総務部長しか分からない」と言われたことがある
• 取引先から「セキュリティ対策の状況を教えてください」というアンケートが届いて困った
• IT機器の入れ替えを提案されたが、金額の妥当性が判断できない
• 株や登記の相談先はあるのに、システムの相談先が社内にも社外にもいない

一つでも当てはまるなら、この記事はあなたのための内容です。

そもそも「サポート終了（EOL)」とは何か

まず前提から整理します。Windows ServerのようなOS（基本ソフト）には、マイクロソフト社が定める「製品ライフサイクル」があります。発売から一定期間は不具合修正や新機能が提供される「メインストリームサポート」、その後は重大な不具合とセキュリティの修正のみに絞られる「延長サポート」という段階を経て、最終的に「サポート終了日」を迎えます。この状態を一般にEOL（サポート終了）と呼びます。

サポートが終了すると何が起きるかというと、脆弱性（ソフトウェアの弱点）が見つかっても、マイクロソフトはそれを修正するパッチ（修正プログラム）を配布しなくなります。攻撃者はサポート終了直後のOSを狙う傾向があるとも言われており、穴が開いたままの家に住み続けるようなものだと考えてください。

承継直後によくある「気づいたきっかけ」

実際にサーバーのサポート終了問題に向き合うことになった承継社長の多くは、自分から気づいたわけではなく、何らかの外部からのきっかけで発覚しています。典型的なパターンを挙げてみます。

• 取引先の大手企業から「情報セキュリティに関するアンケート」への回答を求められ、質問項目に「使用しているサーバーOSのサポート状況」があり答えられなかった
• 銀行の融資審査や事業承継補助金の申請書類で、事業継続計画（BCP）やITリスクへの対応状況を問われた
• 保守契約を結んでいたベンダーから「そろそろサポートが切れるので更新を検討してください」という案内が来たが、内容が理解できず放置していた
• 実際に社内のシステムで原因不明のエラーや動作の遅さが発生し、調べてもらったら「もうサポートが切れているOSでした」と言われた
• 先代からの引き継ぎ資料に「サーバー」という単語自体がほとんど出てこず、承継後に初めてその存在に気づいた

こうしたきっかけに共通するのは、「自社の内部からは問題が見えにくい」という点です。サーバーは日々の業務の中で意識されることがほとんどなく、正常に動いている限り誰も気にしません。だからこそ、外部からの指摘や質問がトリガーになって、初めて問題の存在に気づくケースが大半なのです。逆に言えば、こうした外部からの問いかけを「面倒な事務作業」として流さず、自社の状態を点検する機会だと捉える姿勢が重要になります。

実際、いつサポートが切れるのか——バージョン別の期限

社長がまず知るべきは「うちのサーバーはいつまでか」という一点です。代表的なWindows Serverのバージョンと延長サポート終了日を整理します。

Windows Server 2012および2012 R2は、すでに2023年10月10日（米国時間）に延長サポートが終了しています（出典: IPA 独立行政法人 情報処理推進機構）。もし今、社内にこのバージョンが残っているなら、それは「対応が遅れている」のではなく、すでに「サポート切れ状態が続いている」ということです。至急の確認が必要です。

次の節目はWindows Server 2016で、延長サポートは2027年1月に終了予定です（出典: Microsoft Support）。「まだ先の話」と思うかもしれませんが、後述する通りサーバー入れ替えには半年〜1年単位の計画期間が必要になることが多く、2026年8月現在ですでに逆算を始めるべき時期に入っています。

サポート終了とセキュリティパッチの関係をもう少し丁寧に

「サポート終了＝即トラブル」ではないと述べましたが、なぜそう言えるのか、もう少し丁寧に仕組みを説明します。

OSというのは、家に例えるなら基礎や壁にあたる部分です。日々、世界中の研究者や攻撃者がこの基礎や壁に「弱点」がないかを探しており、実際に弱点（脆弱性）が見つかると、マイクロソフトのような開発元がそれを塞ぐ「修正プログラム（パッチ）」を配布します。これが毎月のように届く「Windows Update」の正体です。

サポート期間中は、新しい弱点が見つかるたびにこの修理が行われ、家は常に補修され続けます。ところがサポートが終了すると、この補修が一切行われなくなります。家自体は壊れていなくても、新しく見つかった弱点はそのまま放置され続け、時間が経つほど穴の数が増えていく——これがサポート終了後のサーバーの実態です。

しかも厄介なのは、こうした弱点情報は世界中に公開されるという点です。修正プログラムが存在しないと分かった弱点は、悪意ある攻撃者にとって「確実に突破できる入り口」として狙われやすくなります。サポートが切れたOSがすぐに攻撃されるとは限りませんが、時間が経つほど、また同種のOSを使う企業が世の中に多いほど、標的にされる可能性は高まっていくと考えるのが安全です。

なぜ「先代の時代のサーバー」がとくに危ういのか

承継した会社のサーバーには、他の会社とは違う特有の危うさがあります。

第一に、導入した本人（先代、あるいは先代の代に契約したベンダーの担当者）がすでにいないことです。何のために、どんな設定で、どのソフトと連携させて入れたのか、経緯を知る人が社内に残っていないケースが少なくありません。これは属人化の典型例で、属人化はシステムの話に限らず経営全般のリスクですが、特にサーバーのような「普段は意識しない基盤」で起きると発見が遅れます。

第二に、サーバーが会計・受発注・顧客台帳など複数の基幹業務を一手に引き受けている場合、そのサーバーが止まれば会社の業務全体が止まるという構造になっていることです。これは単一障害点（SPOF）と呼ばれる状態で、代替手段がない一点に依存している以上、老朽化やサポート終了はそのまま経営リスクに直結します。

第三に、先代の時代は「取引先からセキュリティ状況を聞かれる」機会自体が今より少なかったという事情です。ここ数年、大手取引先を中心に「サプライチェーンセキュリティ」への関心が急速に高まっており、下請け企業に対しても取引条件としてセキュリティ対策の状況を確認する動きが広がっています。先代の感覚のまま「うちは小さい会社だから狙われない」と考えていると、取引の入り口で足元をすくわれかねません。

放置した場合に何が起きるのか、具体的に

「サポートが切れても今すぐ壊れるわけではない」というのは事実です。しかし、それは「今日事故が起きなかった」だけであって、リスクがゼロという意味ではありません。

IPAの注意喚起によれば、Windows Server 2012/2012 R2で2022年7月から2023年6月までに発見された脆弱性のうち、約8割が深刻度の高いものだったとされています（出典: IPA）。サポートが切れたOSでは、この種の深刻な脆弱性が発見されても、二度と修正されません。攻撃者からすれば、いつまでも開いたままの窓のようなものです。

また、サイバー攻撃被害に遭った企業・団体のうち、中小企業が占める割合は決して小さくないという調査結果も報告されています。「大企業が狙われる」というイメージとは裏腹に、防御が手薄な中小企業がランサムウェア攻撃の踏み台や標的になりやすいのが実情です。

「うちは規模が小さいから狙われない」という思い込みこそが、最も危険な脆弱性かもしれません。

万が一ランサムウェアの被害に遭えば、業務データの暗号化・喪失に加え、復旧費用、取引先への説明対応、場合によっては個人情報漏えいの届け出義務など、経営の体力を大きく削る事態に発展します。株式や登記であれば税理士や司法書士という明確な相談先がありますが、サーバーのトラブルは「誰に頼めばいいのか分からないまま被害が拡大する」という点で、承継社長にとって特に厄介な領域です。

「株や登記には専門家がいるのに」という孤独感

事業承継の場面では、株式の評価や名義変更には税理士が、登記の変更には司法書士が、それぞれ当たり前のように相談先として存在します。契約書のチェックが必要なら弁護士に、資金繰りの相談なら銀行の担当者に——承継社長の周りには、法務・財務・税務の専門家がすでに配置されていることがほとんどです。

ところが、システムやITインフラの話になった途端、相談先が急にいなくなります。顧問税理士に聞いても「それは専門外です」と言われ、銀行の担当者もITの中身までは踏み込んできません。結果として、「サーバーの調子が悪い」「サポートが切れると言われた」といった話は、先代の代から惰性で契約している保守ベンダー一社に、そのまま丸投げせざるを得ない状況に陥りがちです。

これは決して社長の能力の問題ではなく、多くの中小企業に共通する構造的な穴です。だからこそ、この記事のような形で「まず何を確認し、誰にどう相談すればいいか」という手順そのものを知っておくことに価値があります。専門家を一人でも見つけて相談できる状態を作ることが、株や登記の専門家を見つけるのと同じくらい、経営の安定にとって重要な備えになります。

まず社長自身がやるべき「棚卸し」

専門家に相談する前に、社長自身、あるいは経理・総務の担当者と一緒にできる確認作業があります。難しい技術知識は不要です。

• サーバー本体（黒い箱、あるいはラックに収まった機器）が社内のどこに何台あるか、写真を撮って把握する
• 電源を入れたときの画面や、契約している保守会社からの書類に「Windows Server」の後ろに続く数字（2012、2016、2019など）が書かれていないか確認する
• そのサーバーで何が動いているか（会計ソフト、受発注システム、ファイル共有、顧客名簿など）を知っている社員に聞き取る
• 保守契約書や購入時の見積書が残っていれば、導入年と契約先ベンダーを確認する

この作業は、社内に散らばった機器・ソフト・契約の情報を一枚にまとめるシステム管理台帳の第一歩でもあります。台帳が一つあるだけで、次に何かトラブルが起きたときの初動が大きく変わります。実際、承継直後の会社では「そもそも何がどこで動いているか誰も把握していない」状態からのスタートになることが多く、この棚卸しだけでも十分に価値のある作業です。

移行のタイムラインを逆算する

対応方針を検討する前に、まず「いつまでに何を終えている必要があるか」を逆算しておくことをお勧めします。サーバーの入れ替えやクラウド移行は、思い立ってすぐに完了する作業ではありません。目安として、次のような工程が必要になります。

1. 現状把握・要件整理（1〜2ヶ月）— 何が動いているかの棚卸し、業務への影響範囲の確認
2. ベンダー選定・見積もり比較（1〜2ヶ月）— 複数社への相談、提案内容の比較検討
3. 設計・準備（1〜3ヶ月）— 新環境の設計、データ移行方法の確定、テスト計画の作成
4. 移行作業・並行稼働・切り替え（1〜2ヶ月）— 実際のデータ移行、旧環境と新環境の並行稼働によるテスト、本切り替え
5. 安定化・アフターフォロー（1ヶ月程度）— 切り替え直後のトラブル対応

単純に合計すると、着手から完了まで半年〜1年程度を見込んでおくのが現実的です。もちろん規模やシステムの複雑さによって短縮も長期化もしますが、「サポート終了日の直前に動き始める」のでは間に合わない可能性が高いという点は覚えておいてください。Windows Server 2016のように残り期限が1年半を切っているケースでは、まさに今が逆算のスタートラインです。

対応の選択肢は主に3つ

サーバーのOSバージョンとサポート終了日が分かったら、次は対応方針の検討です。選択肢は大きく3つに整理できます。

1. 後継OSへの入れ替え（オンプレミス） — サーバー機器ごと新しいものに更新し、最新のWindows Serverを導入する方法。初期費用はかかりますが、長期的には最も安定した選択肢です。
2. クラウドへの移行 — サーバー機器を自社で保有せず、Microsoft AzureなどのクラウドサービスにOS環境を移す方法。機器の老朽化リスクそのものから解放されます。
3. 延長セキュリティ更新プログラム（ESU）の契約 — 今すぐ入れ替えが難しい場合の「時間稼ぎ」の選択肢。有償でセキュリティ更新だけを延長してもらう仕組みです。

ESUについて補足すると、これは「サポート終了後も特定のレガシー製品を使い続けざるを得ない利用者のための最終手段」と位置づけられています（出典: Microsoft Learn）。Azure上で使う場合は無料、オンプレミス環境では有償という違いがあり、いずれも延長できる期間には上限があります（出典: レムシステム株式会社）。つまりESUは恒久策ではなく、「移行の準備が整うまでの猶予」を買う仕組みだと理解しておくべきです。老朽化したサーバーを業務を止めずに段階的に作り変える工程そのものを引き受ける会社（システムリプレース、運営会社ゼットリンカーの受託メニュー）に相談する選択肢もあります。

「とりあえずESUで延命」が危険な理由

予算の都合上、ESUで時間を稼ぐという判断自体は合理的な場合もあります。しかし承継社長が陥りやすい罠は、「延命したこと」で安心してしまい、根本対応を先送りし続けることです。

ESUには有効期限があり、いずれにせよ移行は避けられません。しかも先延ばしにするほど、次の3つが悪化していきます。

• 対応できるベンダーが減る — 古いOSに詳しい技術者は年々減っており、いざ移行しようとしたときに対応できる業者を探すこと自体が難しくなります
• 移行費用が上がる — 機器の老朽化が進むほど、データ移行時のトラブルリスクが高まり、想定外の追加費用が発生しやすくなります
• 業務が複雑に絡み合う — 放置している間にも新しい業務システムが追加され、老朽サーバーへの依存関係がさらに複雑化します

ESUはあくまで「移行計画を立てるための時間」であって、「問題を解決した」ことにはならない——ここを混同しないことが重要です。

ベンダー選びで社長が確認すべき質問

先代の代から付き合いのある保守ベンダーがいる場合も、いない場合も、今回の対応を機に次の質問を投げかけてみてください。相手の説明が誠実かどうかを見極める材料になります。

• 「うちのサーバーは今どのバージョンで、いつサポートが切れますか」に即答できるか
• 移行の選択肢（入れ替え／クラウド移行／ESU）を複数提示し、それぞれのメリット・デメリットを説明してくれるか
• 見積もりの内訳（機器代・作業費・保守費）が明確に分かれているか
• 「よく分からないので全部お任せします」で押し切ろうとせず、社長にも分かる言葉で説明しようとしているか

株式や登記の専門家を選ぶときと同じ感覚で構いません。専門用語で煙に巻かれず、複数の選択肢と根拠を示してくれるかどうかで判断しましょう。可能であれば2社以上から話を聞き、提案内容を比較することをお勧めします。

古参社員との関係で気をつけたいこと

サーバーの入れ替えは、しばしば社内の人間関係にも波及します。特に、先代の時代から総務や経理を担ってきた古参社員が、既存のシステムに強い思い入れや慣れを持っているケースは珍しくありません。「今のままで困っていない」「新しいシステムは覚えるのが大変」といった声が上がることもあるでしょう。

ここで大切なのは、古参社員の意見を頭ごなしに否定しないことです。彼らは日々の業務でそのシステムを使い倒してきた実務知識の持ち主であり、移行プロジェクトにおいては最も重要な情報源にもなります。一方で、「サポート終了」というのは感情や慣れの問題ではなく、期限が決まっている技術的な事実です。社長自身が「これは会社を守るための経営判断であり、いつまでに決めなければならない期限がある」ということを、古参社員にもきちんと説明し、巻き込みながら進める姿勢が求められます。

予算感をどう考えるか

サーバー入れ替えの費用は、企業規模やシステムの複雑さによって大きく変動するため、この記事で断定的な金額を示すことは避けます。ただし、判断の材料として次の視点を持っておくと交渉がしやすくなります。

• 機器そのものの価格に加えて、既存データの移行作業費、旧環境からの切り替えテスト費用がかかる
• 業務システムが古いサーバー専用に作り込まれている場合、システム自体の改修費が発生することがある
• クラウド移行の場合は初期費用が抑えられる一方、月額・年額の利用料が継続的に発生する
• 複数のベンダーから相見積もりを取り、内訳を比較することが最も確実な相場観の掴み方になる

「詳しい人に丸投げして、出てきた金額をそのまま払う」のではなく、内訳を分解して質問できる状態を作ることが、承継社長がこの局面で身につけるべき最低限の武器です。

Excelマクロや古い業務ソフトとの絡みにも要注意

サーバーの入れ替えを検討する際、もう一つ見落とされがちなのが、サーバー上や各PCで動いている周辺の仕組みです。たとえば経理担当者がExcelで長年作り込んできたマクロによる自動処理や、そのサーバー専用に作られた古い業務ソフトが、実は入れ替え対象のサーバーと連携して動いていることがあります。サーバーだけ新しくしても、これらの周辺システムが新環境で動かなくなれば、業務が止まってしまいます。こうした「担当者しか中身を知らない自動化の仕組み」は、先代の時代から少しずつ積み上がってきたものであることが多く、本人が退職・引退した後は誰も触れなくなっているケースが珍しくありません。移行を検討する段階で、「このサーバーに依存している別のシステムやファイルがないか」を必ず洗い出してください。前述の棚卸し作業の中で、この点も合わせて確認しておくと、移行時のトラブルを大きく減らせます。

クラウド移行という選択肢をもう少し詳しく

オンプレミス（自社内に機器を置く方式）での入れ替えとクラウド移行、どちらを選ぶべきか迷う社長も多いでしょう。それぞれの特徴を整理します。

オンプレミスでの入れ替えが向いているケース

• 工場の生産管理システムなど、現場の機器と物理的に密接に連携しているシステムがある
• インターネット回線の品質や速度に不安があり、常時オンラインでの運用に懸念がある
• 情報を自社の建物内で完全に管理したいという方針が明確にある

クラウド移行が向いているケース

• サーバー機器の老朽化・故障・盗難といった物理的なリスクそのものから解放されたい
• 拠点が複数あり、どこからでも同じ環境にアクセスできる利便性を重視したい
• 初期費用を抑え、月額・年額の費用として平準化したい
• 情報システム専任の担当者がおらず、機器の保守・管理をできるだけ外部に任せたい

多くの中小企業にとって、専任の情シス担当者がいない状態でサーバー機器を自社管理し続けることは、それ自体がリスクです。クラウド移行は、サーバーという「物理的に壊れるもの」への依存を減らし、老朽化やサポート終了という問題自体の発生頻度を下げる効果も期待できます。どちらか一方が絶対的に正しいわけではなく、自社の業務内容と体制に合わせて、複数のベンダーの意見を聞きながら判断することが望ましいでしょう。

承継社長だからこそ持てる強み

ここまでリスクの話を中心にしてきましたが、承継社長には実は独自の強みもあります。それは「しがらみなく判断できる立場」にあることです。

先代やその時代の担当者が導入したシステムに対して、現社長は「自分が決めたことではない」という距離感を持てます。これは裏を返せば、「このシステムは本当に今の会社に必要か」をゼロベースで見直せる特権でもあります。承継のタイミングは、属人化した古いシステムを整理し、会社の実態に合った形に作り直す絶好の機会だとも言えます。

先代への敬意を持ちながらも、経営者として今の会社を守るために必要な判断を下す——それがサーバーのサポート終了対応という、一見地味なテーマの本質です。

入れ替えて終わりではない——更新プログラムを当て続ける体制

サーバー入れ替え後も、油断はできません。新しいOSを導入したとしても、その後の更新プログラム（パッチ）を継続的に適用し続けなければ、いずれ同じ問題が繰り返されます。マイクロソフトは毎月、複数の脆弱性を修正する更新プログラムを配布しており、これを定期的に確認し、適用していく作業を怠ると、サポート中のOSであっても穴だらけの状態になってしまいます。

「入れ替えたら終わり」ではなく、「入れ替えた後も定期的に更新を確認・適用する体制を作る」ところまでをワンセットで考えておくと、次に同じような問題に直面するリスクを大きく減らせます。ベンダーに保守を依頼する場合は、更新プログラムを適用する頻度や、誰がその作業に責任を持つのかについても、契約時に確認しておくとよいでしょう。社内に専任の担当者がいない会社ほど、この「地味だが継続する作業」を外部委託する意味は大きくなります。

移行後に「また同じことを繰り返さない」ための仕組みづくり

サーバーの入れ替えが無事に完了したとしても、それで終わりではありません。今回のサポート終了問題がなぜ発覚が遅れたのかを振り返ると、多くの場合「誰も定期的にチェックしていなかった」ことが根本原因にあります。せっかく苦労して新しい環境に移行しても、また同じように放置してしまえば、数年後には同じ問題が繰り返されるだけです。

再発を防ぐために、次のような仕組みを移行と同時に整えておくことをお勧めします。

• 年に1回、IT環境の棚卸しをする日を決める — 決算期や株主総会の準備と同じタイミングで、「システムの棚卸しの日」をカレンダーに組み込んでしまうのが実践的です
• 保守ベンダーとの契約内容を書面で確認する — 「何を、いつまで、いくらで保守してもらえるのか」を口頭ではなく契約書で確認し、担当者が変わっても引き継げる状態にしておく
• サポート終了日をあらかじめカレンダーに登録しておく — 新しく導入するOSやソフトウェアについても、導入時点でサポート終了予定日を確認し、その半年〜1年前にリマインダーを設定しておく
• 社長以外にもう一人、システムの状況を把握する人を作る — 社長一人だけが状況を把握している状態も、それはそれで一種の属人化です。経理担当者や後継予定者など、複数人で情報を共有しておく

こうした仕組みは、特別なITスキルがなくても始められます。大切なのは「システムのことは詳しい人に任せきりにする」のではなく、「経営として定期的に点検する対象である」という意識を持ち続けることです。株主総会や決算と同じように、IT環境の点検も経営サイクルの一部に組み込んでしまうのが、最も確実な再発防止策だと言えます。

補助金や支援制度の活用も視野に

サーバーの入れ替えやクラウド移行には相応の費用がかかるため、資金面で二の足を踏む社長も少なくないでしょう。中小企業のIT投資やセキュリティ対策に関しては、国や自治体がさまざまな補助金・助成金制度を用意している場合があります。制度の内容や公募時期は年度ごとに変わるため、この記事で個別の制度名や金額を断定することは避けますが、検討の際には次の窓口をあたってみることをお勧めします。

• 商工会議所や商工会の経営相談窓口
• 都道府県・市区町村の中小企業向け補助金情報ページ
• 顧問税理士や取引銀行が把握している最新の公募情報
• IT導入支援を行っているベンダー（対象となる補助金の申請支援を行っている場合がある）

補助金は申請から採択まで一定の期間がかかることが多いため、「サーバーが心配になってから急いで探す」のではなく、前述のタイムライン逆算と合わせて、早めに情報収集を始めておくと選択肢が広がります。

まとめ：今日からできる3つの行動

最後に、この記事を読んだ社長が今日からできる行動を3つにまとめます。

1. 社内のサーバーが何のOSで動いているか、まず確認する（分からなければ保守ベンダーや詳しい社員に聞く）
2. そのOSのサポート終了日を調べ、期限までの残り時間を把握する
3. 期限まで1年を切っている、またはすでに終了している場合は、今週中に複数のベンダーへ相談を申し込む

先代が築いた会社を次の世代に引き継ぐためには、目に見える売上や取引先との関係だけでなく、目に見えにくいシステムの土台を健全に保つことも欠かせません。サーバーのサポート終了対応は地味な作業に見えますが、放置すれば会社の存続そのものを揺るがしかねない経営課題です。まずは「うちのサーバーは今、何歳か」を確認するところから始めてみてください。

よくある質問（FAQ）

Q1. サポートが終了しても、サーバーは今まで通り動くのでしょうか？

A. はい、サポート終了日を過ぎても、サーバー自体がすぐに停止したり動かなくなったりするわけではありません。ただし、新たに見つかった脆弱性に対する修正プログラムが提供されなくなるため、セキュリティ上の防御力が徐々に低下していきます。「動いている」ことと「安全である」ことは別問題だと理解しておく必要があります。

Q2. 予算がすぐに用意できません。どうすればいいですか？

A. 延長セキュリティ更新プログラム（ESU）を契約することで、有償ながら一定期間セキュリティ更新を延長できる場合があります。ただしESUには利用できる期間の上限があり、あくまで移行までの猶予を得るための時間稼ぎです。ESU契約中に、次の移行計画（時期・予算・ベンダー選定）を並行して進めることが重要です。

Q3. 先代の代からの担当ベンダーに任せておけば大丈夫でしょうか？

A. 長年の付き合いがあるベンダーは業務内容を理解している点で心強い存在ですが、それだけで判断せず、サポート終了日への対応方針を具体的に説明してもらいましょう。移行の選択肢や見積もりの内訳を明確に示してくれるかどうかで、そのベンダーが今の会社の状況に合っているかを見極めることができます。不安があれば、他社にもセカンドオピニオンとして相談することをお勧めします。

Q4. 社内に詳しい人が誰もいません。何から始めればいいですか？

A. まずは社内にあるサーバー機器の台数と設置場所を確認し、保守契約書や購入時の書類からOSのバージョンを調べることから始めてください。詳しい社員がいなくても、この程度の確認は社長自身でも可能です。そのうえで、複数のITベンダーに「うちのサーバーのサポート状況を確認してほしい」と相談すれば、専門的な診断を受けられます。

この記事の次に読みたい記事

• 先代の退職者PCとアカウント、承継前にやる棚卸しの手順
• 「触ると壊れる」と先代に言われ続けたシステムを調査する順番
• 先代の代からの開発会社と連絡が取れなくなったとき、まず確認すべき3つのこと

承継社長が先に確認する3つの判断（2026年9月7日確認）

OS名だけで入れ替えを発注せず、次の3点を現場と保守先で確認する。以下は判断のための例であり、当社の導入実績ではない。

ESUは対象と期間が限られる。Azure上でESUの追加料金がない場合でも、仮想マシン等の利用料が無料になるわけではない。詳細な終了日時はタイムゾーン表記を含めて公式ライフサイクル表を確認する。