レガシーERP入れ替えガイド【2026年版】基幹システム刷新の進め方・費用・失敗しない方法
老朽化した基幹システム（ERP）を入れ替える際の進め方・費用相場・選定基準・失敗パターンを解説。SAP・Oracle・OBC等からのクラウドERP移行を検討している企業向けガイドです。
目次 クリックで開く
レガシーERP入れ替えガイド【2026年版】
老朽化した基幹システムを刷新するための進め方・費用相場・失敗しない移行計画を解説します。
より網羅的な最新版として、レガシー基幹システム刷新ガイド【2026年版】（奉行11・GLOVIA・SMILE・Access対応）もあわせてご覧ください。本記事は進め方・費用・失敗回避の要点を簡潔に整理したものです。
レガシーERPを入れ替えるべきサイン
| サイン | 詳細 |
|---|---|
| サポート終了・EOL | ベンダーのサポート期限切れ、セキュリティパッチなし |
| 法改正未対応コスト増大 | 電子帳簿保存法・インボイス・電子申告対応のたびに高額カスタマイズが必要 |
| 社員が使いにくい | UI老朽化でミス多発、スマホ・リモート非対応 |
| 他システムとの連携不可 | APIがなく、kintone・Salesforce・MA等との連携が手作業CSV |
| 開発会社が廃業・高齢化 | カスタマイズしたシステムの保守ができる技術者がいない |
| ハードウェア老朽化 | サーバー更新時期到来、仮想化・クラウドへの転換点 |
クラウドERP・クラウド基幹システムへの移行パターン
パターンA：フルリプレイス（完全入れ替え）
既存の基幹システムを一度に新しいクラウドERPに移行します。移行期間中の並行運用コストはかかりますが、将来の技術的負債をゼロにできます。大規模プロジェクトになるため、1〜3年の計画が必要です。
パターンB：段階的移行（フロントシステムから先行）
顧客管理（CRM）・経費精算・勤怠管理などフロント系から先にクラウド化し、後から会計・在庫管理などのバックオフィス系を移行します。リスク分散ができる反面、システム間のデータ連携が複雑になります。
パターンC：ハイブリッド維持（基幹は残しAPI連携）
既存の基幹システムはそのまま維持し、新たなデジタル系業務（EC・CRM・MA）とAPI連携します。短期コストは抑えられますが、基幹の老朽化問題は先送りになります。
主要クラウドERP比較
| ERP | 対象規模 | 強み | 月額目安 |
|---|---|---|---|
| SAP S/4HANA Cloud | 大企業・中堅 | 世界標準・製造業特化機能 | 高額（要見積） |
| Oracle NetSuite | 中堅・グローバル企業 | 会計・在庫・受発注の統合 | 10〜50万円/月〜 |
| マネーフォワード ERP | 中小〜中堅 | 日本法規制対応・使いやすさ | 6〜30万円/月〜 |
| freee 会計+人事 | 中小 | 低コスト・AI仕訳・銀行連携 | 3〜10万円/月 |
| Microsoft Dynamics 365 BC | 中小〜中堅 | M365連携・Copilot AI | 10〜30万円/月〜 |
| 弥生クラウド | 小規模〜中小 | シンプル・低コスト | 1〜5万円/月 |
ERP入れ替えの費用相場
| 規模 | 導入費用（初期） | 月額ランニング | 期間目安 |
|---|---|---|---|
| 小規模（〜50名） | 100〜500万円 | 10〜50万円 | 3〜6ヶ月 |
| 中規模（50〜300名） | 500〜3,000万円 | 30〜200万円 | 6〜18ヶ月 |
| 大規模（300名〜） | 3,000万円〜数億円 | 100万円〜 | 1〜3年 |
レガシー ERP の入れ替えで本当に難しいのは「いつ動くか」の判断
レガシー ERP の入れ替えプロジェクトで失敗する企業の多くは、製品選定や実装の問題ではなく、「いつ動き始めるか」「いつ完了させるか」の経営判断でつまずいています。サポート切れ・人材不足・業務制約という3つの圧力がかかり始めているのに、3年放置して結果として「2027年問題」のような全社危機に発展する。これがレガシー ERP 刷新の最も典型的な失敗パターンです。
この記事は ERP 製品の比較ではなく、レガシー ERP 入れ替えという経営判断のタイミングと進め方に焦点を当てます。年商50〜500億の中堅企業が直面する3つの圧力と、それぞれにどう向き合うかを書きます。
3つの圧力：サポート切れ・人材不足・業務制約
レガシー ERP が継続困難になる理由は、ほぼ全社で3つの圧力のいずれかから始まります。最初は1つだけ顕在化していても、放置すると3つが重なり、緊急対応の選択肢が狭まります。
圧力1：ベンダーサポート切れ
SAP ECC 6.0 の2027年メインストリームサポート終了、Oracle EBS 12.2 の Premier Support 終了、独自パッケージのベンダー事業撤退——これらが最も明確で、回避できない圧力です。サポート切れ後も自社で運用継続することは技術的には可能ですが、セキュリティパッチが止まり、税制改正への対応が止まり、ベンダー保守契約も切れるため、3〜5年スパンでは事業継続リスクになります。
この圧力に対しては、明確なデッドラインから逆算してプロジェクト期間を確保するしかありません。SAP ECC → S/4HANA 移行は18〜36ヶ月、Oracle EBS → Oracle ERP Cloud 移行は12〜24ヶ月かかるため、サポート切れの3年前には意思決定する必要があります。
圧力2：運用人材の確保困難
レガシー ERP の運用には、その製品特有の知識を持つ技術者が必要ですが、これらの人材市場が縮小し続けています。COBOL 開発者、SAP ABAP 開発者、Notes/Domino 管理者、AS/400（IBM i）運用者——いずれも50代以上のベテランに依存し、退職が連続すると組織が運用継続不能に陥ります。
この圧力は緩やかに進行するため、危機感を持ちにくいのが厄介な点です。「あと5年は何とかなる」と思っているうちに、キーパーソン2名の退職で一気に運用が回らなくなることが多発しています。キーパーソン3名以上いる企業は今すぐ移行検討、2名なら2年以内、1名なら緊急対応が現実的な目安です。
圧力3：業務制約と機会損失
レガシー ERP では、新規事業・サブスク販売・グローバル展開・EC 連携・データ分析基盤など、新しい業務要件への対応が困難になります。これは「動かなくなる」のではなく「事業の足を引っ張る」圧力で、経営層には見えにくいのが特徴です。
典型的に表面化するのは、新規事業の検討会議で「現状の基幹システムでは対応できない」が繰り返し出てきたタイミングです。営業現場では「Excel と手作業で何とか回している」状況が常態化し、結果として競合に対する事業スピードで差がついていきます。
3つの移行戦略：Lift & Shift / Re-platform / Re-architect
移行の進め方は大きく3戦略に分かれ、それぞれリスクとコストが大きく異なります。多くの企業が安易に Lift & Shift を選び、その後で後悔するパターンが続いています。
Lift & Shift（現状業務をそのまま移行）
現状の業務フローを変えずに、新しい ERP 上で再現する戦略です。業務側の負担は最小ですが、新 ERP の機能を活かせず、運用コストが従来とあまり変わらないのが欠点です。SAP ECC → S/4HANA 移行を Lift & Shift で行うと、HANA の高速性を活かせず、Fiori UX も部分的にしか使えません。
Lift & Shift が合理的なのは、「サポート切れデッドラインまで時間がない」「業務改革のリソースがない」「とりあえずサポート期限を回避したい」という緊急避難の場面です。中長期的には Re-platform への移行を計画する前提でないと、5〜10年後にまた同じ問題に直面します。
Re-platform（業務をクラウド ERP の標準機能に合わせる）
クラウド ERP の標準機能を最大限活用し、独自カスタマイズを最小化する戦略です。業務側に「現状業務を変える」覚悟が必要ですが、運用コスト・バージョンアップ追従性・人材確保のしやすさで、最も成功率が高い戦略です。
Re-platform を成功させるには、業務側のキーパーソンが「標準機能で要件を満たすには何を諦めるか」を判断する力が必要です。情シス任せにすると、業務側の抵抗で結局カスタマイズが膨らみます。業務側 PM の力量が、Re-platform の成否を分けるのが現実です。
Re-architect（事業構造から再設計）
事業構造そのものを見直し、ERP を完全に新設計する戦略です。新規事業立ち上げ・M&A による業態転換・グローバル展開のタイミングでないと、現実的に取れない選択肢ですが、競争力の源泉になる可能性があります。
Re-architect は実質的に経営戦略レベルの判断で、ERP 単体の話を超えます。経営層が主導しないと進まないため、情シスから提案して採用されることはほぼありません。
規模別の現実的な選択
年商規模別に、現実的な戦略の選び方を整理します。
年商50〜200億の中堅企業では、Re-platform が標準的な選択です。クラウド ERP（Microsoft Dynamics 365 BC、SAP Business One、NetSuite、奉行クラウド）の標準機能で業務を回す前提で、3年スパンで段階的に移行します。プロジェクト総額は1〜5億円程度です。
年商200〜1,000億の中堅大企業では、Lift & Shift と Re-platform の併用が現実的です。コア業務（会計・購買・販売）は Re-platform で再構築し、業界特化機能・独自競争優位部分は段階的に Re-architect する。プロジェクト総額は5〜30億円規模です。
年商1,000億超の大企業では、SAP S/4HANA への移行が中心になります。グローバル展開・複数業態を抱えるため、テンプレート化された SAP Activate 方法論に従う方が安全で、独自カスタマイズは最小化する判断が増えています。プロジェクト総額は30〜数百億円規模です。
プロジェクト推進体制で失敗しないために
ERP 入れ替えで失敗する企業の共通点は、推進体制にあります。「情シスが主導」「業務側はレビューのみ」の体制は、ほぼ確実に失敗します。情シスは技術側の課題は把握できますが、業務側の妥協ライン・優先順位・現場の抵抗を交渉する権限と知見を持っていません。
成功する体制は、業務側のキーパーソン（経営企画 or 事業部長クラス）が PM を務め、情シスが技術 PM として伴走する形です。さらに経営層がスポンサーとして月次で進捗をレビューし、業務側の妥協ラインを決める権限を持つ。この3層体制が機能している企業のみが、3年スパンの ERP 入れ替えを完走できます。
判断材料：今すぐ動くべきかの自己診断5問
レガシー ERP の入れ替えタイミングを判断するために、次の5問で自社の状況を確認してください。3問以上「YES」なら、今期中に意思決定すべきフェーズに入っています。
- 使用中の ERP のメインストリームサポートが3年以内に終了するか
- 運用に必須のキーパーソンが2名以下で、うち1名以上が55歳以上か
- 新規事業の検討で「現基幹システムでは対応できない」が複数回出ているか
- 月次決算が翌月10営業日以降に確定する状態が3ヶ月以上続いているか
- 過去2年で、ERP 関連の障害・税制改正対応の遅延が発生しているか
業種別に見る、レガシー ERP 入れ替えのリアル
製造業：BOM・原価計算が最大の壁
製造業のレガシー ERP 入れ替えで圧倒的に重い論点が、BOM（部品表）と原価計算です。長年運用してきた製造業の BOM データには、廃番部品・代替部品・季節品・客先別仕様などが複雑に絡み合い、新 ERP に「そのまま移行」は事実上不可能です。BOM データのクレンジング・正規化に、移行プロジェクト全体の20〜30%の工数が消えていくのが、製造業の現実です。
原価計算も同様に難しい。標準原価・実際原価・配賦ルール・部門別配賦・製品別配賦——これらが企業ごとに独自設計されており、新 ERP の標準ロジックに合わないことが多い。Fit to Standard を目指しても、原価計算だけはカスタマイズせざるを得ない、というのが製造業の暗黙の前提です。経営層には、原価計算のカスタマイズコストを最初から予算化しておくことを推奨します。
商社・卸売：与信管理と長期取引の表現
商社・卸売業のレガシー ERP には、与信管理・長期契約・複数通貨・委託販売・買掛買戻し条件など、複雑な取引パターンが組み込まれています。これらを新 ERP の標準機能で再現できるかが、選定の決定打になります。SAP S/4HANA・Oracle ERP Cloud は対応していますが、中堅向けクラウド ERP（Dynamics 365 BC・NetSuite）では設定で工夫が必要なケースがあります。
もう一つの論点は、貿易事務（輸出入手続き・L/C・船積書類・通関）です。これらを ERP 内で扱うか、別 SaaS（FAINS・NACCS 連携製品）で扱うかで、システムスタックが変わります。商社・卸売の ERP 入れ替えは、ERP 単体ではなく業務システム全体の再設計に近い性質を持ちます。
建設業：工事原価と進行基準会計
建設業のレガシー ERP では、工事台帳・工事原価管理・進行基準会計（IFRS 15 / ASC 606）が中核機能です。これらは一般 ERP の機能では十分対応できず、建設業特化の ERP（PROCES.S・ガリオン・オリコン・コンストラクション ERP 等）が選ばれる理由になります。
建設業の入れ替え検討では、汎用 ERP（SAP・Oracle・Dynamics）と業界特化 ERP の比較が必須です。汎用 ERP で建設業要件を満たそうとすると、追加カスタマイズで初期費用が業界特化版の2〜3倍になることがあります。「業界特化版で標準対応できる業務範囲」と「汎用 ERP で必要なカスタマイズ範囲」を比較した上で選定すべきです。
サービス業：プロジェクト会計と工数管理
SI・コンサル・広告代理店などのサービス業では、プロジェクト会計（案件別収益・原価・利益管理）と工数管理が ERP の中核機能になります。これらは一般 ERP より、NetSuite SuiteProjects・Dynamics 365 Project Operations・Salesforce Service Cloud + 工数管理アドオンのような「プロジェクト ERP」カテゴリで強い製品があります。
サービス業の ERP 入れ替えで見落とされがちなのが、Salesforce との統合です。営業活動が Salesforce、案件管理が新 ERP、という分離設計では、案件のステージ更新が二重作業になります。「Salesforce + プロジェクト ERP」の統合度を、選定軸の上位に置くべきです。
移行プロジェクトの体制設計
レガシー ERP 入れ替えのような3年スパンのプロジェクトでは、体制設計が成否を分けます。経営層・業務側・情シス・SI ベンダー・パッケージベンダーの5者が関わり、それぞれの役割と権限を最初に明文化しないと、プロジェクトの後半で必ず揉めます。
経営層：意思決定スポンサー
経営層の役割は「意思決定」です。プロジェクト進捗の細かな管理ではなく、月次の経営会議で「変えるべき業務」「残すべき業務」を最終判断する。業務側と SI ベンダーの間で対立した時、判断を下す権限を持つのは経営層のみです。経営層がこの役割を果たさないと、現場の声に押されてカスタマイズが膨張します。
業務側 PM：プロジェクトオーナー
業務側 PM（経営企画・事業部長・経理部長クラス）が、プロジェクト全体のオーナーになります。情シスやベンダー任せにすると、業務要件の解釈ミスで完成物が現実業務と合わなくなる。業務側 PM は週20〜30時間をプロジェクトに割く前提でないと、機能しません。兼任で月数時間のレベルでは、決断のスピードが追いつきません。
情シス：技術 PM
情シスは「技術 PM」として、システム設計・インフラ・連携・セキュリティを担当します。業務要件の優先順位付けは業務側 PM の役割、技術的な実装判断は情シスの役割、と明確に分けます。情シスが業務要件まで決めると、現場が「自分たちが決めたことではない」と離れていきます。
SI ベンダー：実装パートナー
SI ベンダーは、要件定義・設計・実装・テスト・運用支援の実務を担当します。重要なのは、SI ベンダーに「業務要件を決める権限」を渡さないことです。業務要件は業務側 PM が決め、SI はそれを実装する立場に徹する。SI ベンダーが業務要件まで提案し始めると、業務側 PM の権限が形骸化します。
パッケージベンダー：製品サポート
SAP・Oracle・Microsoft などのパッケージベンダーは、製品機能・標準ロジック・バージョンアップ情報を提供する役割です。SI ベンダーとは別契約で関係を持つことを推奨します。SI ベンダー経由でしか情報が来ない状態だと、SI の都合の良い情報しか入らない構造になります。
切替方式：ビッグバン vs 段階移行
移行の切替方式は、ビッグバン（一斉切替）と段階移行（部門別・拠点別・機能別の順次切替）の2つに分かれます。それぞれメリットとリスクがあり、自社に合わせて選ぶ必要があります。
ビッグバン切替
ある日（多くは決算月の翌月初日）に、全部門・全業務を一斉に新 ERP に切り替える方式です。並行運用期間が短く、移行プロジェクト全体の期間を短縮できる利点があります。一方で、切替日にトラブルが発生すると業務全体が止まるリスクが大きく、失敗のインパクトが甚大です。
ビッグバン切替が向くのは、中小規模（年商50〜200億）で業務がシンプルな組織、または期限が厳しい場合（サポート切れデッドラインが迫っている等）です。事前のリハーサル・並行運用テスト・ロールバック手順の整備が、ビッグバン成功の条件になります。
段階移行
事業部別・拠点別・機能別（会計→販売→購買→在庫→生産の順など）に、3〜12ヶ月かけて段階的に切り替える方式です。リスクが分散され、各段階で学習・改善ができる利点があります。一方で、新旧2システムの並行運用期間が長くなり、現場の業務負荷が継続する欠点があります。
段階移行が向くのは、大規模（年商500億超）・複数事業部・複数拠点の組織です。プロジェクト総期間は12〜36ヶ月、各段階の切替で月次決算3回完了を区切りとする、というのが標準的な進め方です。段階移行は安全だが、業務側 PM の体力が試される方式でもあります。
移行コストの真の内訳
レガシー ERP 入れ替えのコストは、よく「初期構築費」と「ライセンス費」だけで議論されますが、実際は次の6項目が積み上がります。中堅企業（年商200〜500億）の標準的なプロジェクトでは、次のような内訳になります。
初期構築（30〜40%）：要件定義・設計・実装・テスト。SI ベンダー費用が大半。ライセンス（20〜30%）：5年スパンのクラウド ERP ライセンス。SAP S/4HANA Cloud で年額数千万〜数億円。データ移行（10〜15%）：マスタクレンジング・データ変換・移行テスト。想定より工数が膨らみがち。並行運用・現場負荷（10〜15%）：新旧2システム並行運用期間の人件費増加。残業代・派遣費・外部支援費。教育・トレーニング（5〜10%）：全社向け e-Learning・ハンズオン・キーパーソン育成。運用立ち上げ（5〜10%）：稼働後3〜6ヶ月のハイパーケア体制。
稟議書には全6項目を分けて書くことを推奨します。「ライセンス費だけ」で稟議を取ると、稼働後にデータ移行費・並行運用費・教育費の追加稟議が発生し、組織内の信頼を失います。最初から総コストで議論する方が、長期的に信頼を得られます。
基幹システムの刷新・移行とデータ統合のご相談
老朽化した基幹システムの刷新やERP移行、社内システム同士のデータ連携を、業務を止めない形で支援します。移行方式や構成が妥当かを確認したい、という導入前後のセカンドオピニオンにも対応しています。
関連ガイド・クラスター
基幹システム入れ替えのご相談はAurant Technologiesへ
現状の基幹システム診断から移行先選定・データ移行・CRM/AI連携まで一貫サポート。無駄のない移行計画を一緒に設計します。
よくある質問
- Q. ERP入れ替えプロジェクトが失敗する最大の原因は何ですか？
- A. 要件定義の不十分さと「現行踏襲」への固執が最大の失敗原因です。既存業務のすべてをそのままERPに再現しようとすると、クラウドERPの標準機能を活かせずカスタマイズ過多になり、コスト超過・スケジュール遅延につながります。
- Q. ERP入れ替え中も業務を止めないようにできますか？
- A. 並行運用期間を設けることで業務を止めずに移行できます。ただし並行期間中は両システムへの入力作業が発生するため、並行期間は最短（1〜3ヶ月）に設計することを推奨します。