システムEOL対応の費用相場｜進め方と選び方

システムのEOL対応では、対象製品だけでなくOS、データベース、実行環境、連携先まで調査し、延長保守・更新・移行・再構築を比較します。一般的な費用は小規模更新で50万〜300万円、基盤を含む移行で300万〜3,000万円以上が目安です。期限の12〜18カ月前から着手すると、緊急対応と予算超過を避けやすくなります。

• システムEOLとは何か、最初に確認すべきこと
  • EOLを過ぎても直ちに停止するとは限らない
  • 製品名とEOL日だけでは判断できない
  • 期限が迫っている場合の暫定対策
• EOL対応の4つの選択肢と選び方
  • 1．延長保守で移行期間を確保する
  • 2．現行製品をバージョンアップする
  • 3．クラウドなど新しい基盤へ移行する
  • 4．再構築またはSaaSへ移行する
• EOL対応の費用相場・期間と見積もりの見方
  • 費用を左右する主な要因
  • 見積書で分けてほしい項目
• EOL対応を外注する手順と開発会社の選び方
  • ステップ1．対象と優先順位を整理する
  • ステップ2．外注先へ渡す資料を準備する
  • ステップ3．対応案と概算費用を比較する
  • ステップ4．事前検証とテスト計画を確認する
  • ステップ5．移行リハーサルと切り替えを行う
  • 開発会社を見極める質問
  • よくある失敗と回避策
• まとめ
• よくある質問
  • システムのEOL対応はいつから始めるべきですか？
  • EOLを過ぎたシステムは直ちに停止しなければなりませんか？
  • バージョンアップと再構築はどのように選べばよいですか？
  • EOL調査だけを開発会社へ依頼できますか？

システムEOLとは何か、最初に確認すべきこと

EOL（End of Life＝製品・バージョンの提供や保守が終了する時点）への対応で最初に必要なのは、通知された製品だけを更新することではなく、システム全体の依存関係を把握することです。

業務システムは、アプリケーションだけで動いているわけではありません。サーバーのOS、データベース、プログラムの実行環境、外部サービスとの連携、監視ツールなど、複数の製品やバージョンが組み合わされています。1つを更新すると、別の製品や独自開発部分が動かなくなることもあります。

EOLを過ぎても直ちに停止するとは限らない

EOLを迎えたシステムが、その日から必ず利用できなくなるわけではありません。しかし、次の問題が段階的に大きくなります。

• セキュリティパッチ（＝脆弱性を修正する更新）が提供されなくなる
• 障害が発生しても製品ベンダーへ問い合わせられない
• 新しいOS、ブラウザ、端末、外部サービスに対応できない
• 監査や取引先のセキュリティ確認で説明が難しくなる
• 古い技術を扱える担当者や開発会社が減少する
• 故障時に交換部品や代替環境を用意できない
• 緊急移行となり、比較検討や十分なテストができなくなる

特に外部公開されているWebシステムや、個人情報・決済情報を扱うシステムは、利用できていることと安全に運用できることを分けて判断する必要があります。

製品名とEOL日だけでは判断できない

発注のご相談を受ける開発会社の立場から見ると、EOL通知だけを持参し、「この製品を更新するといくらですか」と相談されるケースは少なくありません。しかし、製品名と終了日だけでは正確な見積もりは困難です。

最低限、次の対象を一覧にします。

複数の製品が連鎖している場合、最も早いEOL日だけを見るのではなく、更新先のバージョンがほかの構成要素と互換性を持つかまで確認します。

期限が迫っている場合の暫定対策

EOLまで3カ月を切っている、またはすでに期限を過ぎている場合は、全面移行を急いで品質を落とすより、リスクを抑える暫定対策と恒久対応を分ける方が現実的です。

暫定対策として確認したい項目は次のとおりです。

• ベンダーに延長保守の提供可否を確認する
• インターネットから接続できる範囲を制限する
• 管理者権限と利用アカウントを棚卸しする
• バックアップから実際に復元できるか確認する
• 障害や不正アクセスの監視を強化する
• 変更作業を必要最小限に制限する
• 経営層、情報システム部門、利用部門で残存リスクを共有する
• 恒久対応の責任者と期限を決める

延長保守は時間を確保する手段であり、恒久対応ではありません。延長期間中に調査や移行を完了させる計画をセットで作る必要があります。

EOL対応の4つの選択肢と選び方

EOL対応は、単純なバージョンアップだけではありません。延長保守、現行製品の更新、基盤移行、システム再構築・SaaS移行という4つの選択肢を、事業継続性と中長期の総費用で比較します。

1．延長保守で移行期間を確保する

延長保守は、製品ベンダーや保守会社が通常のサポート終了後も限定的な支援を提供する契約です。業務の繁忙期とEOLが重なる場合や、移行に必要な予算を翌年度に確保する場合に使われます。

ただし、延長保守で受けられる内容は契約によって異なります。問い合わせには対応しても新しい修正プログラムは提供されない、対応時間が限定される、といった条件もあります。

契約前に次を確認してください。

• 脆弱性修正が提供されるか
• 障害時の問い合わせ窓口と受付時間
• 対応する製品・バージョンの範囲
• 延長可能な期間と終了日
• 年額・月額費用と更新条件
• 対応対象外となる事象

2．現行製品をバージョンアップする

業務機能に大きな問題がなく、現行製品の後継バージョンが提供されている場合は、バージョンアップが第一候補です。ただし、複数の世代を一度に飛び越えて更新すると、画面仕様、データ形式、設定方法が変わり、アプリケーション改修が必要になることがあります。

「製品のインストール費用」と「業務システムを動かすための改修・テスト費用」は分けて考えることが重要です。製品更新自体は短期間でも、既存機能の確認に時間がかかることがあります。

3．クラウドなど新しい基盤へ移行する

物理サーバーや古いデータセンター環境のEOLを機に、クラウドへ移行する方法です。単純に同じ構成を新環境へ移すだけでなく、バックアップ、監視、アクセス制御、障害復旧の方法も見直します。

クラウドへ移せば自動的にEOL問題がなくなるわけではありません。クラウド上でもOSやデータベースを自社管理する構成では、継続的な更新が必要です。ベンダーが更新を管理するサービスを採用すると運用負担を減らせますが、利用料や移行制約との比較が欠かせません。

4．再構築またはSaaSへ移行する

SaaS（＝インターネット経由で利用する既製のソフトウェア）への移行や再構築は、次のような場合に検討します。

• 現行システムに使われていない機能が多い
• 業務手順とシステム仕様が合わなくなっている
• 独自改修が多く、バージョンアップが難しい
• 保守できる技術者が限られている
• 数年以内に別の製品もEOLを迎える
• 事業拡大に対して性能や機能が不足している

EOL対応を「現在と同じものを作るプロジェクト」とすると、不要な仕様まで引き継いでしまいます。再構築する場合は、現行機能の一覧だけでなく、実際に使われている業務と今後必要な機能を整理します。

選択肢を決める際は、初期費用だけでなく、5年程度のライセンス、クラウド利用料、保守、更新、人員を含む総費用で比較することが有効です。

EOL対応の費用相場・期間と見積もりの見方

EOL対応の費用は、対象製品の価格よりも、影響調査、アプリケーション改修、データ移行、テスト、停止時間の制約によって大きく変わります。以下は一般的な目安であり、税金、製品ライセンス、クラウド利用料、機器購入費などは別途必要になる場合があります。

同じ製品の更新でも、利用者が数人の社内ツールと、複数拠点が利用する基幹システムでは必要なテストや移行計画が異なります。停止可能な時間が短いほど、並行稼働やリハーサルが必要になり、費用が上がる傾向があります。

費用を左右する主な要因

見積もりを依頼する前に、次の条件を整理すると金額の根拠が分かりやすくなります。

• サーバー、データベース、利用拠点、利用者の数
• 独自開発した機能とソースコードの有無
• データ件数、容量、保存期間、移行対象
• 外部システムや周辺機器との連携数
• 本番環境を停止できる曜日と時間
• テスト環境を新たに用意する必要があるか
• 現行ベンダーから資料やデータを受け取れるか
• 新旧環境を並行稼働させる期間
• セキュリティ、監査、法令への対応条件
• 深夜・休日作業の有無

予算を検討する際は、調査費、開発・移行費だけでなく、製品ライセンス、インフラ利用料、社内担当者の作業、予備費、移行後の保守費まで含めます。予算の組み立て方は、システム開発予算の決め方｜発注前の算定手順も参考にしてください。

見積書で分けてほしい項目

EOL対応の見積書は、「移行一式」ではなく、少なくとも次の項目に分かれていることが望ましいです。

ロールバック（＝切り替えに失敗した場合に旧環境へ戻すこと）は、見積もりから抜けやすい項目です。「予定時間内に終わらなかった」「重要機能に不具合が出た」といった場合に、誰が何を基準に戻すかまで決めておきます。

また、固定金額の見積もりであっても、前提条件を確認してください。「既存プログラムは修正不要」「データ不整合はない」「現行ベンダーから資料が提供される」などの前提が外れると、追加費用が発生します。

EOL対応を外注する手順と開発会社の選び方

EOL対応は、調査、方針決定、検証、移行、運用開始の順に進めます。最初から更新方法を決め打ちせず、現状調査の結果を踏まえて対応案を比較することが重要です。

ステップ1．対象と優先順位を整理する

まず、EOL対象を一覧化します。製品名、バージョン、終了日、管理部門、利用業務、外部公開の有無、保存データ、障害時の影響を記載します。

複数の対象がある場合は、次の観点で優先順位を付けます。

• 売上や顧客対応への影響が大きいか
• 個人情報や機密情報を扱うか
• インターネットから接続できるか
• 代替手段があるか
• 障害時に復旧できるか
• ほかのシステムが依存しているか
• 保守担当者や資料が残っているか

EOL日が近いものだけでなく、事故が起きた場合の事業影響が大きいものを優先する考え方が必要です。

ステップ2．外注先へ渡す資料を準備する

資料が完全にそろっていなくても相談はできます。ただし、「資料がないこと」も事前に伝えることで、調査工数を見積もりに含めてもらえます。

依頼前の準備チェックリストは次のとおりです。

• EOL通知やベンダーからの案内
• システム構成図とネットワーク構成図
• 製品、バージョン、サーバーの一覧
• ソースコードと保管場所、アクセス権
• 外部連携、バッチ処理、帳票の一覧
• データ容量と保存期間
• 運用手順書、障害履歴、問い合わせ履歴
• 現行の保守契約とライセンス契約
• 利用部門、利用人数、繁忙期
• システムを停止できる時間
• 予算の上限または予算化する時期
• 希望する完了時期と動かせない期限

RTO（＝障害発生後、何時間以内に復旧するかという目標）とRPO（＝障害時に、どの時点までのデータを復旧するかという目標）が決まっている場合は、あわせて共有します。未決定であれば、利用部門と相談しながら決められる会社を選びます。

ステップ3．対応案と概算費用を比較する

開発会社には、単一案だけでなく複数案を提示してもらうと判断しやすくなります。例えば、次のような比較です。

• 延長保守を利用して翌年度に移行する案
• 最小限のバージョンアップで数年間延命する案
• クラウドへ移行し、運用負担も減らす案
• 業務を整理してSaaSまたは新システムへ移す案

比較時には、初期費用、毎年の運用費、次回のEOL時期、移行リスク、社内負担をそろえて確認します。初期費用が安くても、2年後に再度大規模更新が必要であれば、結果的に高くなることがあります。

ステップ4．事前検証とテスト計画を確認する

本番移行前に、更新先の環境で独自機能や外部連携が動くかを検証します。特に、古いプログラム、複雑な帳票、文字コード、周辺機器、夜間バッチは問題が見つかりやすい領域です。

テストは画面が開くことだけでなく、次の範囲を含めます。

• 主要な業務が最初から最後まで完了するか
• 既存データと移行後データが一致するか
• 外部システムへ正しいデータを送受信できるか
• 利用者が集中する時間帯に処理できるか
• バックアップから復旧できるか
• 権限のない利用者が情報へアクセスできないか
• 障害発生時に監視通知が届くか
• 新環境で帳票やファイルの内容が変わらないか

回帰テスト（＝更新前に動いていた機能が更新後も正常に動くかを確認するテスト）の対象と、実施担当者も明確にします。業務上の正しさは開発会社だけでは判断できないため、利用部門にも受け入れ確認へ参加してもらいます。

ステップ5．移行リハーサルと切り替えを行う

データ量が多い場合や停止時間が短い場合は、本番データに近い条件で移行リハーサルを行います。作業時間、データ件数、エラー、照合結果を記録し、当日の手順を修正します。

切り替え計画には、次の内容が必要です。

• 作業開始と終了の時刻
• 作業担当者と意思決定者
• 利用停止を周知する方法
• データ更新を止める時刻
• 移行後の確認項目と合格基準
• 作業を継続するか中止するかの判断時刻
• ロールバックの条件と手順
• 利用再開後の問い合わせ窓口

移行後は一定期間、監視と問い合わせ対応を強化します。安定稼働を確認するまでは、旧環境をすぐに削除しない判断もあります。ただし、旧環境を残す期間、アクセス権、削除日を決めなければ、費用と情報漏えいリスクが残ります。

開発会社を見極める質問

EOL対応を依頼する会社には、製品知識だけでなく、影響調査と移行管理の能力が求められます。提案時には次の質問をしてください。

• 現行システムの構成と依存関係をどう調査しますか
• 互換性がない場合、どのように切り分けますか
• 見積もりの前提条件と対象外は何ですか
• データ移行の照合方法をどう設計しますか
• リハーサルは何回を想定していますか
• 切り替えを中止する基準は何ですか
• セキュリティ更新と権限をどう見直しますか
• 移行後にどの資料と設定情報を納品しますか
• 将来のEOLをどのように管理しやすくしますか
• 障害が起きた場合の連絡・対応体制はどうなりますか

会社を比較する際は、特定製品の実績件数だけでなく、調査方法、リスクの説明、見積もりの透明性、運用まで含めた提案を確認します。システム開発会社の選び方｜発注前の比較ポイントもあわせてご覧ください。

よくある失敗と回避策

EOL対応では、期限を守ることに集中するあまり、移行後の運用や周辺システムが抜けることがあります。

EOLは一度対応すれば終わりではありません。移行後も、利用製品、バージョン、サポート終了日、担当者、次回確認日を台帳で管理し、少なくとも予算策定の時期に見直せる運用を作ります。

自社の対象範囲が分からない、複数案の費用を比較したい場合は、現状調査の段階から開発のご相談はこちらよりご相談ください。

まとめ

• EOL対応では、通知された製品だけでなく、OS、データベース、実行環境、外部連携まで調査します
• EOL後も直ちに停止するとは限りませんが、脆弱性修正や障害対応を受けられないリスクがあります
• 対応方法は、延長保守、バージョンアップ、基盤移行、再構築・SaaS移行の4案を比較します
• 一般的な費用は、小規模更新で50万〜300万円、基盤を含む移行で300万〜3,000万円以上が目安です
• 中規模以上のシステムでは、EOLの12〜18カ月前から調査を始めると選択肢を確保しやすくなります
• 見積書では、調査、改修、テスト、データ移行、切り替え、ロールバック、旧環境廃止を分けて確認します
• 開発会社は価格だけでなく、依存関係の調査方法、移行リハーサル、リスク説明、運用資料まで比較します
• 移行後は製品とEOL日を台帳化し、次回更新を予算計画へ組み込みます

よくある質問

システムのEOL対応はいつから始めるべきですか？

中規模以上の業務システムであれば、一般的にはEOLの12〜18カ月前から調査を始めると選択肢を確保しやすくなります。小規模な更新でも、検証や社内承認を考慮して6カ月程度は見込むのが安全です。

EOLを過ぎたシステムは直ちに停止しなければなりませんか？

EOLを過ぎたからといって、通常は直ちにシステムが停止するわけではありません。ただし、脆弱性修正やベンダーサポートを受けられない可能性があるため、外部公開範囲の制限、バックアップ確認、監視強化などの暫定対策を行い、早急に更新・移行計画を決める必要があります。

バージョンアップと再構築はどのように選べばよいですか？

現行システムの機能や設計を今後も利用でき、対応バージョンへ無理なく更新できる場合はバージョンアップが有力です。老朽化した独自仕様が多い、保守できる人材がいない、事業要件が大きく変わっている場合は、再構築やSaaSへの移行も含めて比較します。

EOL調査だけを開発会社へ依頼できますか？

はい、調査だけでも依頼できます。依頼時には、対象製品とバージョンの一覧、依存関係、影響範囲、対応案、概算費用、想定期間、優先順位を成果物として受け取れる契約にすると、その後の社内判断や相見積もりに活用しやすくなります。