レガシーシステム更改の開発期間は、ベンダーの保守契約満了やOS・ミドルウェアのEOS/EOLという動かせない期限から逆算して組み立てます。工程と体制を期限から先に決めておけば、先送りのリスクも抑えられます。
「レガシーシステムのモダナイゼーション」はリホストからリプレースまでの技術手法の使い分けを、「レガシーシステム刷新」は経営層の投資判断や稟議承認を中心に扱っています。本記事は、保守契約終了やOSのサポート終了告知という具体的な期限から逆算して、開発期間・スケジュール・納期をどう組み立てるかに焦点を当てます。
▼全体ガイドの記事
・レガシーシステム更改の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム更改の定義（契約満了・EOS/EOLという外圧トリガーで動く更改）
レガシーシステム更改は、メインフレームやCOBOLで書かれた古い基幹システムなど、すでにレガシー化したシステムを、外部から強制される期限をきっかけに入れ替える取り組みです。「まだ動いているから」という理由で入れ替えを先送りにする企業は少なくありませんが、更改の時期は自社の都合だけで決められるものではありません。
ベンダーの保守サポート契約満了やハードウェアのリース期限、OS・ミドルウェアのEOS/EOL（End of Support／End of Life）は、企業の意向とは無関係に外部から強制されます。そのため、これらの期限が更改プロジェクトの実質的なデッドラインになります。
外圧トリガーの性質を押さえることが、開発期間とスケジュールを現実的に組み立てる出発点になります。
メインフレーム・COBOLシステムのベンダー保守契約満了という具体的トリガー
メインフレームやCOBOLで構築された基幹システムのような大規模な独自ハードウェア・ソフトウェアは、事業への影響が大きいため、サポート終了の3〜5年前に、ロードマップとともに公式なアナウンスが行われるのが一般的です。
しかし、この予告を受け取ってから検討を始める企業は少なくありません。通知が来てから移行方針を決めても、大規模で複雑なシステムでは移行そのものに1年以上かかるため、直前の対応では到底間に合いません。
加えて、国産メーカーによるメインフレーム・UNIXサーバー事業からの撤退も相次いでおり、長年延長を重ねてきた保守契約が「これ以上の延長は不可能」という形で打ち切られるケースも増えています。契約満了通知は、開発期間・スケジュールを決める最も重要な起点として扱う必要があります。
OS・ミドルウェアのEOLという外圧（Windows Server、Windows 10、CentOS等）
レガシーシステムを支えるOS・ミドルウェアのサポート終了も、更改を強制する外圧として無視できません。実際に、2023年10月にはWindows Server 2012／2012 R2の延長サポートが終了し、2024年6月にはCentOS 7のサポートが終了しました。そして2025年10月には、一般利用者にも馴染み深いWindows 10のサポートまでもが終了しています。
世界的な基幹業務システムであるSAP ERP（ECC6.0）も、標準保守サポートが2027年末に終了する「2027年問題」が確実に迫っています。これらのEOLは、システムの機能や業務要件とは関係なく、あらかじめ決められた日付に一方的にやってくる点が最大の特徴です。
まずは自社のレガシーシステムがどのOS・ミドルウェアの上で稼働しているかを洗い出し、それぞれのEOLの期日をカレンダーに書き込むことが、開発期間を検討する最初の一歩になります。
期限から逆算する開発期間・スケジュールの目安
契約満了・EOLという期限が明確な更改プロジェクトでは、上流から積み上げるのではなく、デッドラインから逆算してスケジュールを組みます。そのために欠かせないのが、各工程に配分できる期間を先に割り出す「タイムボックス型」の発想です。
更改本体の実作業だけでなく、その手前のリードタイムも含めて全体像を把握しておく必要があります。
通知を受けてから着手までに発生する見落とされがちなリードタイム
ベンダーから保守契約終了やEOLの通知を受け取っても、すぐに開発工程へ入れるわけではありません。まず現行システムの資産・機能・データ量を洗い出し、RFP（提案依頼書）を作って複数のベンダーから提案を募ります。そのうえで比較して発注先を決め、社内で予算の承認を得るという一連のプロセスが必要です。
特にメインフレーム・COBOLシステムの場合は、仕様書が実態と合っていないことが多く、洗い出しの段階だけで数ヶ月かかることも珍しくありません。
リードタイムを見込まず、「通知から逆算した残り期間」だけで開発期間を計算すると、着手する頃にはすでに納期に間に合わない状況に陥ります。
更改本体（現状分析〜データ移行・UAT）の工程別期間目安
リードタイムを終えて更改本体の工程に入ると、現状分析・企画・ベンダー選定に約2〜3ヶ月、要件定義に約3〜4ヶ月かかります。さらに、設計・開発に約4〜6ヶ月、テスト・データ移行・UAT（ユーザー受け入れテスト）に約3〜5ヶ月かかります。これは、大規模な基幹系システムを12〜18ヶ月程度で更改する場合のおおよその工程別目安です。
メインフレームからオープン系・クラウド環境へ移行する場合は、複数回にわたるデータ移行リハーサルが不可欠です。この工程を軽視すると、本番切り替え直前に想定外の不整合が発覚し、全体のスケジュールを押し戻す最大の要因になります。
契約満了・EOLの期日は動かせないからこそ、テスト・移行フェーズには十分な余裕を持たせた工程を組む必要があります。
更改を先送りした場合のセキュリティリスク・障害時サポート不能リスク
更改の開発期間を検討する際、「間に合わなければ、もうしばらく今のシステムを使い続ければよい」と安易に考えるのは危険です。
契約満了・EOLという期限を過ぎて稼働し続けることには、後戻りのできない具体的なリスクが伴うことを理解しておく必要があります。
EOL後のセキュリティ脆弱性放置というリスク
OS・ミドルウェアがEOLを迎えると、ベンダーは新たに発見された脆弱性に対する修正パッチの提供を停止します。これは今すぐ表面化するものではなく、攻撃者に狙われやすい脆弱性が塞がれないまま、日を追うごとに積み重なっていくリスクです。
ランサムウェアなどの攻撃を受けて重大な情報漏えいや事業停止に至れば、直接的な復旧費用に加えて、損害賠償や信用の失墜も伴います。そのとき生じる損失は、更改を先送りして節約したはずのコストをはるかに上回りかねません。
特に、メインフレーム・COBOLで構築された基幹システムは、顧客情報や取引データなど重要度の高い情報を扱うことが多くあります。そのため、脆弱性を放置するリスクは事業全体に波及しやすい点を認識しておく必要があります。
障害発生時にベンダー支援が受けられない長時間業務停止リスク
保守契約が満了した後にシステム障害が起きると、これまで当たり前に受けられていたベンダーの復旧支援を得られなくなります。原因調査から復旧作業まで、自社か限られた協力会社だけで対応せざるを得ず、その遅れがそのまま業務停止時間の長期化に直結します。
加えて、古いハードウェアが故障すると、生産終了によって代替部品を入手できず、修理そのものが不可能になるケースもあります。さらに、古い技術に対応できる保守担当者も高齢化や退職で減っており、いざというときの対応力はいっそう弱まります。
契約満了・EOLという期限は、「サポートが受けられなくなる日」であるだけでなく、「業務が止まったときに誰も助けてくれなくなる日」でもあります。この捉え方で、開発期間の緊急性を正しく評価できます。
期限に間に合わせるための進め方
契約満了・EOLという期限は動かせないため、遅れを前提に計画を立てるのではなく、期限内に安全に終えるための進め方そのものを工夫する必要があります。
一括移行を避ける段階移行・パイロット移行・並行稼働
期限に間に合わせようとするあまり、全機能を一斉に切り替える「一括移行（ビッグバン）」を選ぶと、万が一トラブルが起きたときに長時間のシステム停止という致命的な事態を招きます。これに対して、「段階移行」「パイロット移行」「並行稼働」を組み合わせると、リスクを局所化しながら期限内に終えられます。
段階移行は、EOLの緊急性が特に高いコア機能から優先的に新環境へ移す方式です。パイロット移行は、特定の部門・拠点だけで先行導入して問題点を洗い出す方式です。並行稼働は、新旧システムを同時に動かして実データで検証する方式です。
各機能について、いつまでに、どの方式で移行するかをあらかじめ一覧にしておくことが、期限内の完遂に欠かせません。
第三者保守サービスによる暫定延命という選択肢
どれだけ計画を工夫しても、開発期間の見通しがEOLの期日に間に合わないと判明する場合があります。そうしたときの現実的な選択肢が、純正ベンダー以外の企業がハードウェア・ソフトウェアの保守を請け負う「第三者保守サービス」の活用です。
EOSを迎えた機器でも一定期間はサポートを受けられるため、更改プロジェクトを終えるまでの時間を安全に稼げます。ただし、第三者保守はあくまで一時的な延命策であり、新たな脆弱性への根本的な対応にはならない点に注意が必要です。
期限に間に合わない可能性が見えた段階で早めに検討すれば、プロジェクトのスケジュールに無理な短縮を強いずに済みます。その結果、納期と品質の両方を守ることにつながります。
依頼先選定と着手判断が期間に与える影響
同じ契約満了・EOLの期限を抱えていても、どのパートナー企業に依頼するか、そしていつ着手判断を下すかによって、実現可能なスケジュールは大きく変わります。
レガシー技術者不足時代の依頼先選定基準
メインフレームやCOBOLに対応できる技術者は年々希少になっており、人材の高齢化や退職が進んでいることは、多くの調査で共通の課題として指摘されています。
そのため、依頼先を選ぶ際は、対象言語・基盤の解析実績、自動変換ツール（コンバーター）の活用実績、契約満了・EOLを見据えた更改での類似規模の実績を、具体的な数値とともに確認します。そうすれば、期限内に終えられるという見立ての妥当性を検証できます。
実績が乏しいパートナーに依頼すると、現状の洗い出しの段階からつまずき、ただでさえ厳しい期限がさらに圧迫されるリスクが高まります。
着手判断を先送りするほど選択肢と期間の余裕が失われる構造
契約満了・EOLという期限は、着手を先送りしても動いてはくれません。むしろ先送りするほど、選べる進め方の幅は狭まっていきます。
期限まで十分な余裕があれば、段階移行やパイロット移行といったリスクの低い進め方を選べます。一方で、期限直前になって動き出すと、一括移行に近い強行スケジュールを選ばざるを得なくなり、それに伴うリスクも跳ね上がります。
さらに、着手が遅れるほど有力なパートナーのリソースは埋まり、希望する体制を確保できないおそれも高まります。そのため、契約満了通知やEOLのアナウンスを受け取った時点か、それより前に、現状の洗い出しへ着手しておくことが大切です。自社の更改の緊急度と現実的な選択肢を整理しておくことが、期限内に安全に終えるための最も有効な備えになります。
まとめ
レガシーシステム更改の開発期間は、技術的な作業量だけでなく、ベンダーからの通知後に発生するリードタイムと、契約満了・EOLという動かせない期日の両方を織り込んで、初めて現実的なものになります。
更改を先送りするほど、セキュリティリスクと障害時のサポート不能リスクは静かに積み上がり、選べる進め方も狭まっていきます。
技術手法の詳細は「レガシーシステムのモダナイゼーション」、経営判断・稟議承認の詳細は「レガシーシステム刷新」の各記事もあわせてご参照ください。そのうえで、まずは自社のレガシーシステムの契約満了日とEOLの期日を正確に洗い出すことをお勧めします。
▼全体ガイドの記事
・レガシーシステム更改の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。
レガシーシステム更改の検討では、まず期限管理の対象を次の3点に分けて確認します。
- 外部期限と着手判断の把握。
- 工程と必要な体制の逆算。
- 先送り・障害・依頼先のリスク管理。