レガシーシステムリニューアルの見積相場や費用/コスト/値段について

レガシーシステムのリニューアル費用は、200万円から数十億円まで幅があります。その幅は、対象の規模、ブラックボックス化、データ移行の複雑さで決まります。

規模別の費用相場、レガシー特有の増加要因、予算配分と削減策の順に扱います。全体像は、レガシーシステムリニューアルの完全ガイドもご覧ください。

▼全体ガイドの記事
・レガシーシステムリニューアルの完全ガイド

レガシーシステムリニューアルの費用相場【規模別一覧】

基幹システムの企業規模別と業務システム・Webアプリの費用目安を4枚のパネルで示した図。
対象の種類と企業規模で、見積もりの幅が分かれます。

費用は、対象システムの規模、複雑度、老朽化の程度によって大きく変わります。新規開発より高くなりやすいのは、調査や解析の工数が加わるためです。

基幹システム・ERPの費用目安

基幹システムは、業務の範囲と規模によって費用の幅が広がります。

  • 中小企業向け:3,000万〜1億円程度
  • 中堅・大企業向け:1億〜数十億円
  • レガシー特有の上乗せ:新規開発費の20〜40%

中小企業向けの金額は、従業員50〜300名規模を想定しています。COBOLやVB6からJavaやPythonへ移す場合は、コード解析だけで500万〜2,000万円かかることがあります。

パッケージを使うFit to Standard方式でも、2,000万〜5,000万円の投資が必要です。

中堅・大企業向けの金額は、従業員300名〜数千名規模を想定しています。20〜30年稼働したメインフレームでは、調査だけで1億円を超える場合があります。さらに、大手製造業のERP刷新では、5億〜20億円規模のプロジェクトもあります。

上乗せ費用には、解析やデータクレンジングのほか、ドキュメント整備や移行リハーサルが含まれます。

業務システム・Webアプリの費用目安

業務システムやWebアプリは、基幹系より小規模でも、構成によって費用が変わります。

  • 業務システム:500万〜5,000万円
  • Webアプリ刷新:200万〜3,000万円

業務システムの金額は、受発注管理、在庫管理、顧客管理などの業務を対象にした費用です。なお、Excel VBAからWebへ置き換える場合は、500万〜1,500万円程度です。

複数システムを統合する場合は、2,000万〜5,000万円程度を見込みます。データ移行の複雑さが、業務システムの費用を大きく左右します。

古いフレームワークや技術スタックの刷新では、コードの複雑度によって費用が変わります。たとえば、PHP4やASP.NET WebFormsからの移行で構成がシンプルなら、200万〜500万円です。一方で、複雑なビジネスロジックを持つ大規模Webアプリでは、1,000万〜3,000万円程度です。

ポイント

社内で費用を説明するときは、まず規模区分ごとの幅を見て、そこにレガシー特有の上乗せ(新規開発費の20〜40%)を重ねて考えます。上乗せ分を最初から入れておけば、途中での追加予算を減らせます。

レガシー特有のコスト増要因

レガシーシステムを中央に置き、ドキュメントの有無、データの汚れ、旧ベンダーとの交渉を注釈線で示した図。
見積もりでは、仕様・データ・ベンダーの状態が論点になります。

費用が膨らむ最大の理由は、レガシー特有の「見えないコスト」です。この要因を把握しないまま予算を組むと、途中で大幅な追加予算が必要になります。たとえば、当初の見積もりから費用が2〜3倍に膨らむケースも珍しくありません。

ドキュメント不在・ブラックボックス解析の費用

長期稼働したシステムでは、設計書や仕様書が失われている場合があります。

  • 解析工数:通常の要件定義の2〜5倍
  • 解析費用:中規模基幹系で500万〜3,000万円の例

「動いているが、なぜ動くか分からない」状態は、珍しくありません。そのため、開発会社はソースコードや動作ログから現行仕様を逆エンジニアリングします。コード量が多いほど、解析費用は膨らみます。

数十年使うベテラン社員が唯一の「生きたドキュメント」になる場合もあります。そのため、属人化したノウハウのヒアリングと文書化は、プロジェクトの成否を左右する投資です。

データクレンジングにかかる想定外のコスト

長年の運用で、データにはさまざまな負債が蓄積します。そのため、データクレンジングが想定の3倍かかったと言われるプロジェクトもあります。

  • 費用を左右する要素:データ量、汚染度、移行先の制約
  • 中規模移行の費用例:200万〜1,000万円
  • 文字コード:変換できない例外の確認・修正が必要

主な例は、入力ルールの不統一と重複マスタです。このほか、NULL値や文字コードの混在があります。

作業は4段階で、まず対象データを調べ、次にルールを決めます。そのうえで、変換プログラムを開発し、最後に検証します。

シフトJIS、EUC-JP、ISO-2022-JPをUTF-8へ統一すると、人手による確認が増えます。さらに、数十年分の取引データでは、ビジネスロジックの変更に伴う換算や加工も必要です。

旧ベンダーからの情報引き出し・移行交渉コスト

旧ベンダーから情報やソースコードを得るには、時間と費用がかかります。

  • 移行支援費用:数百万円〜数千万円の要求例
  • 並行運用:旧ベンダーの保守費用が二重になる場合

旧ベンダーには情報開示の義務がないため、高額な移行支援費用を請求する場合があります。独自技術やフォーマットを使うベンダーロックインでは、交渉力が旧ベンダー側に偏ります。

契約解除や保守の終了で、違約金や解約手数料が発生する場合もあります。そのため、発注側は保守契約を確認し、法務部門と連携して移行スケジュールを設計します。

また、旧システムと新システムの並行運用は、数ヶ月〜1年程度になることがあります。

ポイント

見積もりの幅を左右するのは、ドキュメントの有無、データの汚れ、旧ベンダーとの交渉の3点です。判断に迷ったら、この3点が見積もりに含まれているかを先に見ます。

費用の内訳と工程別コスト構造

調査・分析、要件定義・設計、開発・テスト・移行の3層に、全体費用に占める割合を添えた図。
開発・テスト・移行が費用の大きな割合を占めます。

レガシーのコスト構造は、新規開発とは異なります。特に、調査・分析への投資が、後続工程のコストを抑えることにつながります。

調査・分析フェーズ(レガシー特有)

現行機能と技術的負債を把握して、後続工程の前提をそろえる工程です。

  • 機能・業務:機能の洗い出しと業務フローの整理
  • コード:解析とリバースエンジニアリング
  • データ:構造調査と移行可能性の評価
  • リスク:技術的負債の評価レポート作成

このフェーズには、全体費用の10〜20%を充てることが推奨されます。

費用の目安は、機能の棚卸しとヒアリングが50万〜300万円、ソースコード解析が100万〜1,000万円です。データ構造調査は50万〜300万円、技術的負債とリスクの評価レポートは30万〜200万円です。調査費を削ると、後続工程での手戻りリスクが高まります。

要件定義・設計フェーズ

調査結果を踏まえて、新システムの要件と設計を具体化します。

  • 要件定義:新システムの要件の整理
  • アーキテクチャ:全体構成とデータの設計
  • UI:画面と業務プロセスの設計

レガシーのリニューアルでは、現行の業務をどこまで踏襲し、どこから業務改革を進めるかのバランスを、この段階で決めます。費用は全体の15〜25%で、中規模の場合は300万〜800万円程度です。

複雑なロジックを整理するには、業務部門との会議やレビューが増えます。その過程で作る要件定義書、業務フロー図、データモデル図が、後続工程の品質を支えます。

開発・テスト・移行フェーズ

このフェーズは、費用全体の60〜70%を占める最大の工程です。

  • 開発:新システムの実装
  • テスト:各種試験と移行リハーサルの実施
  • 移行:切り替えと並行運用の実施

レガシーでは移行の比重が高いため、テスト・検証の費用も増えます。テスト工数は、新規開発の1.5〜2倍になることがあります。さらに、移行リハーサルは複数回行うことが推奨され、1回数百万円の例もあります。

Fit to Standard方式なら、フルスクラッチより30〜50%の削減が期待できます。一方で、並行運用は3ヶ月〜1年程度が目安で、運用費も予算に含めます。深夜・休日対応を含むカットオーバー支援費用も、別途必要です。

【独自】「ケチってはいけない予算」と「削れる予算」

予算を配分するには、削れる費用と削れない費用を見極める必要があります。特に、重要な投資を削ると、失敗のリスクが高まります。

絶対に削ってはいけない3つの領域

次の3領域は、費用削減の対象から外す必要があります。

  • 調査・分析:現行仕様を把握する費用
  • データ移行:移行前の品質を整える費用
  • 移行リハーサル:切り戻しに備える費用

調査を省くと、後から要件が増えたり、現行と新システムの動作がずれたりします。そのため、調査・分析には全体予算の15〜20%を確保するのが合理的です。

データ品質が悪いまま移行すると、稼働後に業務停止や信頼失墜を招きます。

本番に近い環境で複数回リハーサルを行うと、移行時の問題を減らせます。並行運用を短縮しすぎると、問題発生時に旧システムへ戻せません。

優先度を下げてよい「Nice to Have」の見極め方

初期リリースに不要な機能を見極めれば、費用を抑えられます。

  • 未使用レポート:誰も使っていない機能
  • 不要機能:過去の名残で現業務に不要な機能
  • 画面の踏襲:細かな見た目を現行どおりにする要件
  • 高度な分析:Phase2へ回せるBIダッシュボード

発注側は、「現行と同じでなければならない」という思い込みを、業務上の必要性から見直します。そのうえで、「なくなったら、どの頻度でどれだけ困るか」をユーザー部門に確認します。

月1回未満の機能や、なくても業務が回る機能はPhase2以降へ回せます。優先度を整理すると、初期開発費用を20〜30%削減できる場合があります。

ポイント

予算を削るときは、削ってよい機能と、削ってはいけない工程を分けて判断します。機能を削るかどうかは、なくなったときにどの頻度でどれだけ困るかで決めます。

コスト削減の実践テクニック

予算に制約がある中でも、リスクを抑えながら効率を上げることが大切です。

AI活用によるレガシーコード解析の工数削減

AIを使うと、レガシーコードの理解と文書化を効率化できます。

  • コード理解:旧言語のロジック説明の生成
  • 仕様整理:大量の仕様書の要約
  • 変換案:新言語への変換案の作成

GitHub CopilotやChatGPT・ClaudeなどのLLMを活用できます。COBOLやFORTRANの解析・文書化では、工数を30〜60%削減できる例があります。

ただし、AIの解析結果は人間がレビューする必要があり、完全な自動化は困難です。また、AIツールの費用は月額数万円程度で、解析工数の削減効果に比べると小さい金額です。

段階的リニューアルによる投資分散

全体を一度に変えるビッグバン移行では、リスクと費用が大きくなります。段階的に進める場合は、次の順で移行します。

  1. フロントエンドを先に刷新し、バックエンドは旧システムを使う
  2. 業務影響の少ない周辺機能から移行する
  3. 最後に中核の基幹機能を移行する

この手法は、ストラングラーフィグパターンとも呼ばれます。第一フェーズの費用を、500万〜2,000万円程度に抑えられる場合があります。

各段階で効果を確認できるため、失敗のリスクを限定できます。一方で、旧システムとの連携維持に追加費用がかかります。移行が2〜5年に及ぶ場合もありますが、中小企業にとっては現実的な選択肢です。

Fit to Standardで開発工数を最小化

Fit to Standard(F2S)は、パッケージの標準機能に業務を合わせる考え方です。

  • 対象パッケージ:SAP、Microsoft Dynamics、kintone、ServiceNow
  • 削減効果:フルスクラッチより開発費を40〜60%削減できる例

現行踏襲や業務に合わせたカスタマイズから、標準機能の活用へ転換します。

ライセンス費用は、SAPの場合で年間数百万〜数千万円です。そのため、5〜10年のTCO(総所有コスト)で比較する必要があります。さらに、業務変更の経営判断と、現場の抵抗を抑える変更管理の費用も必要です。

ポイント

コストを下げる手段は、AIによる解析、段階的な移行、Fit to Standardの3つです。どの手段も、リスクを抑えながら効率を上げられるかを基準に選びます。

ROI算出と経営層への説明方法

予算の承認を得るには、費用だけでなく、投資の理由と効果を示す必要があります。数億円規模の投資では、説得力のある費用対効果の説明が欠かせません。

投資対効果の算出フレームワーク

ROIは、コスト削減効果と事業価値の向上効果の2つで算出します。

  • コスト削減:保守、障害対応、非効率業務の費用
  • 事業価値:意思決定、開発速度、機会損失への効果

保守費は年々増える傾向があるため、移行後は年間数百万円〜数千万円の削減が期待できます。障害対応や手作業、二重入力を減らせば、人件費も抑えられます。

データ活用で意思決定を速め、新機能開発の期間も短縮できます。新機能の追加が、数ヶ月から数週間になる場合もあります。システム障害による機会損失も効果に含めて、5年間のROIで示します。

「リニューアルしない場合のリスクコスト」の可視化

放置した場合のリスクコストを示すと、投資の必要性を説明しやすくなります。

  • 停止リスク:業務停止による売上機会損失と人件費
  • セキュリティ:攻撃、賠償、信頼失墜の損害
  • 保守費:5年後・10年後の増加額
  • 技術者確保:旧言語技術者の採用・人件費

停止リスクは、1日当たりの業務停止による損失額を試算します。セキュリティは、サポート切れのOSやミドルウェアのリスクを算出します。保守費は、現行ベンダーの増加傾向を5年後と10年後で示します。

COBOLなどの技術者は、人件費高騰と採用難で確保しにくくなります。また、5年間のリスクコストが、リニューアル費用の1.5〜3倍になる試算もあります。

まとめ

レガシーシステムの費用は、規模と複雑さで大きく変わります。基幹システム・ERPは3,000万〜数十億円が目安で、業務システムは500万〜5,000万円、Webアプリは200万〜3,000万円です。

ドキュメント不在、ブラックボックス化、データの複雑さで費用は変動します。新規開発費に加えて、レガシー特有の費用を20〜40%上乗せして見込みます。

調査・分析、データクレンジング、移行リハーサルは、削れない投資です。この3領域を削ると、プロジェクト失敗のリスクが高まります。

コスト削減には、AIによる解析、段階的移行、Fit to Standardが有効です。AI活用では、コード解析工数を30〜60%削減できる例があります。

予算が限られる中小企業には、段階的移行とFit to Standardが現実的です。放置時のリスクコストと比べると、リニューアル投資に価値がある場合が多くあります。

予算計画を詰め、経営層に説明する材料を整えましょう。

見積もりでは、複数のベンダーから提案を得て比べます。また、調査フェーズを先行発注し、実態把握後に本開発の見積もりを依頼する方法もあります。

▼全体ガイドの記事
・レガシーシステムリニューアルの完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。