「老朽化した基幹システムをそろそろ移行したい。でも、何から始めて、どんな順序で、いくらかかるのか」——中堅企業の経営層から、こうした問いが届きます。レガシーマイグレーション（古い基盤から新しい基盤への移行プロジェクト）は、進め方を誤ると 当初予算を大きく上回る・要件定義が長期化する・本番切替後の業務影響が大きくなる といったリスクにつながります。本記事では、レガシーマイグレーションの定義、5 ステップの進め方、規模別の費用・期間目安、よくある失敗パターンを整理します。
『レガシーマイグレーション、何から始めてどう進めるか整理したい』 25 年の経験で、現状システムと業務要件から最適な進め方を一緒に整理します。 無料相談 ＞結論：レガシーマイグレーションは『5 ステップ × 対象範囲に合わせた予算設計』で進める
レガシーマイグレーションの成否は、『進め方の 5 ステップを丁寧に実行できるか』と『対象システムの規模に合った予算・期間を確保できるか』 に大きく左右されます。順序を飛ばすと要件漏れ・想定外コストが発生しやすく、対象範囲に合わない過大投資・過小投資はプロジェクトのリスクになります。
| 観点 | 整理ポイント | 判断軸 |
|---|---|---|
| ① 進め方 | 現状アセスメント → 移行戦略策定 → ベンダー選定 → 移行実行 → 運用最適化 | 各ステップに必要な期間を確保し、順に進める |
| ② 予算規模 | 対象サブシステム数・画面数・帳票数・外部連携数・データ移行量で大きく変動 | 初期費用＋ 5 年運用費＋社内工数を含めた 5 年 TCO で比較 |
| ③ 期間 | 規模・手法で 12～30 ヶ月の幅 | 段階移行 vs 一括移行で大きく変わる |
本記事では上記 3 観点をそれぞれ詳説します。『どこから手をつけていいか分からない』なら、まず現状アセスメント（ステップ ①）から始める のが安全です。手法選定（リホスト／リライト／リプレース）はその後のステップ ② で決めます。
レガシーマイグレーションとは｜定義・対象範囲
レガシーマイグレーション（Legacy Migration） とは、企業が長年使ってきた古い基盤（汎用機・オフコン・古いオープン系サーバなど）で稼働しているシステムを、新しい基盤へ移行するプロジェクトの総称です。クラウド移行に限らず、オンプレからオンプレ、汎用機からオープン系、古いオープン系から新しいオープン系、パッケージ／SaaS 移行も含む広い概念です。
レガシーシステムの典型
「レガシー」と呼ばれる対象は多岐にわたります。中堅企業で見られる典型的なレガシーシステムは次のとおりです。
| レガシーの種類 | 主な技術 | 典型的な状況 |
|---|---|---|
| 汎用機（メインフレーム） | IBM z/OS／COBOL | 大量バッチ処理、保守費・運用費の高止まり、技術者不足 |
| オフコン | IBM i／AS/400／富士通／NEC／日立 | RPG／COBOL／専用言語、保守契約・ハードウェア更新・技術者確保の課題 |
| 古いオープン系 | Windows Server／Linux／Java | OS・DB のサポート切れ、技術者退職 |
| 独自開発の業務システム | VB／Delphi／古いフレームワーク | 開発者離脱、改修できない |
| Excel／Access の業務基盤化 | VBA／マクロ／Access DB | 属人化・データ整合性なし |
レガシーマイグレーションとモダナイゼーションの違い
混同されやすい 2 語ですが、ニュアンスに違いがあります。
| 用語 | 主な意味合い | 視点 |
|---|---|---|
| モダナイゼーション | レガシーを「現代化」する 経営判断・戦略 全般 | 経営・戦略視点（広義） |
| レガシーマイグレーション | レガシーシステムを新基盤へ「移行」する プロジェクト実行 | プロジェクト・技術視点（狭義） |
実務的には 『モダナイゼーションを実現するための手段の一つがレガシーマイグレーション』 という関係です。経営層が目的・投資判断を示し、情シスや業務部門が具体的な移行プロジェクトとして実行する、という連携が重要になります。
レガシーマイグレーションの進め方｜5 ステップ
実務では、次の 5 ステップ で整理すると進めやすくなります。各ステップに必要な期間と、ステップを飛ばした場合のリスクを整理します。
ステップ① 現状アセスメント（2～3 ヶ月）
最初に 現行レガシーシステムの棚卸し を行います。サブシステム構成・プログラム本数・データ量・依存関係・利用部門・業務影響度・属人化状況・ドキュメント整備状況を可視化します。中堅企業では、長年の改修や担当者交代により、現行システムの全体像を把握しきれていないケースも少なくありません。対象範囲が広い場合、このアセスメントを短期間で済ませようとすると、後の要件定義で手戻りが発生しやすくなります。
ステップ② 移行戦略策定（1～2 ヶ月）
アセスメント結果をもとに 移行手法（7R／6R）を選定 します。リホスト／リプラットフォーム／リファクタリング／リパーチェス／リタイア／リテイン／リロケートのどれを使うか、サブシステムごとに割り当てます。同時に、移行先基盤（IaaS／PaaS／SaaS）・段階移行 vs 一括移行・予算規模・期間の 仮説を整理 します。『どの手法か』ではなく『どの手法をどの順序で組み合わせるか』が中堅企業の有効な選択肢 です。
ステップ③ ベンダー選定・契約（2～4 ヶ月）
戦略を提示し、可能であれば複数社、目安として 2～3 社程度 から提案を取り、比較選定します。『価格』だけでなく、『同業種実績・移行手法の知見・要件定義の精度・運用フェーズの体制』 を評価軸に加えてください。中堅企業では「大手ベンダーは費用が高すぎる」「専門ベンダーは規模に合うが事例数が少ない」というジレンマがあり、業務独自性と予算のバランスで判断します。現行仕様が不明確な場合は、要件定義費用とその後の開発費用を別契約にする ことで、不本意な追加費用を防ぎやすくなります。
ステップ④ 移行実行（6～20 ヶ月）
要件定義・設計・開発・データ移行・テスト・並行稼働・本番切替を順に実施します。並行稼働期間は、月次・四半期・年次処理など、確認すべき業務サイクルに応じて設計 します。販売管理や会計など重要システムでは、少なくとも主要な締め処理を 1 回以上確認できる期間を確保することが安全です。データ移行では 文字コード変換・固定長／可変長変換・マスタ統合・コード体系変更・過去データの範囲決定・法定保存対応・移行リハーサル が想定より工数を取るケースが多くあります。要件定義段階で必ず別建てで見積もってください。
ステップ⑤ 運用最適化（移行後 6～12 ヶ月）
本番稼働は 『ゴール』ではなく『スタート』 です。運用フェーズでは、操作研修・現場フィードバック反映・パフォーマンス監視・クラウドコスト最適化（FinOps）・セキュリティ運用を継続的に行います。移行プロジェクトを稼働日で打ち切ると、現場が新システムに定着せず、旧 Excel や旧帳票による補完運用が残ってしまうことがあります。業務変更が大きい場合は、目安として 稼働後 90 日～ 1 年程度の定着化フォロー を予算に含めておくと安全です。
規模別の費用・期間目安
レガシーマイグレーションの費用・期間は、対象システム範囲・現行システムの複雑度・移行手法 によって大きく変動します。中堅企業の典型的な目安を整理します。
| 対象範囲の目安 | 典型的な対象範囲 | 初期費用目安（当社想定） | 期間 |
|---|---|---|---|
| 小規模（50～150 名規模が目安） | 1～2 サブシステム（販売管理・会計など） | 3,000 万～8,000 万円 | 12～18 ヶ月 |
| 中規模（150～300 名規模が目安） | 主要サブシステム全体（販売・購買・在庫・生産・会計） | 5,000 万～1.5 億円 | 15～24 ヶ月 |
| 大規模（300 名以上規模が目安） | 基幹システム全体＋周辺系 | 1 億～3 億円 | 20～30 ヶ月 |
前提条件：上記は当社想定の概算です。従業員規模ではなく、対象サブシステム数・画面数・帳票数・外部連携数・データ移行量をもとに見た概算であり、従業員数はあくまで参考目安としてご覧ください。実際の費用・期間は、対象範囲・画面数・帳票数・バッチ本数・外部連携数・データ移行量・テスト範囲・並行稼働期間・要件定義の深さ・業務改革の有無・パッケージのカスタマイズ量・クラウド／ライセンス費用・運用保守範囲 によって大きく変動します。一般相場ではなく自社想定の概算としてご覧ください。
中堅企業で見落としやすいのが 『実質総費用』 です。ベンダー支払額に加えて、社内工数（要件定義参加・テスト参加・研修参加）・運用切替期間の人件費・並行稼働期間の重複コスト が発生します。当社経験上の目安として、これらを含めた実質総費用は、ベンダー支払額の 1.3～1.5 倍程度 で見ておくと安全です。予算策定時に必ず別建てで見積もってください。
レガシーマイグレーションの『よくある失敗パターン』
失敗 1：現状アセスメントを省略する
「現状は分かっているから」とアセスメントを短期間で済ませ、いきなりベンダー選定に入るパターン。結果として要件定義フェーズで「実は使われていないサブシステムが多数あった」「依存関係が想定より複雑だった」 ことが判明し、計画が延びることがあります。主要基幹システムを対象にする場合は、現状アセスメントに 2 ヶ月程度を見込む と安全です。
失敗 2：『手法』だけ先に決めてしまう
「リプレース（パッケージ移行）でいく」とアセスメント前に決めてしまい、独自業務が多くてパッケージで吸収できないことが要件定義段階で判明するパターン。業務独自性が明らかになる前に手法を確定しない ことが重要です。
失敗 3：並行稼働期間を短縮する
「コストを下げたい」「早く本番にしたい」という理由で並行稼働を短縮しすぎた結果、本番切替後にデータ整合性問題・性能問題・業務ルールの差異が発覚し、業務影響が大きくなる パターン。並行稼働期間は、対象業務の締め処理や繁忙期、データ同期方式を踏まえて設計してください。
失敗 4：定着化フォローを計画しない
稼働をプロジェクトの終了と捉え、稼働後の現場研修・フィードバック反映・運用最適化を計画していないパターン。現場が新システムに定着せず、旧 Excel・旧帳票による補完運用が残る ことがあります。業務変更が大きい場合は、目安として稼働後 90 日～ 1 年程度の定着化フォローをプロジェクト範囲に含めておくと安全です。
失敗 5：『すべて 1 つの手法』に揃えようとする
基幹システムは複数サブシステムで構成されており、サブシステムごとに最適な手法は異なる のが普通です。「全部リホスト」「全部リプレース」と一律に決めると、独自性の高いサブシステムが不適合になります。サブシステム単位で 7R を組み合わせる設計が有効です。ただし、データ連携や移行順序が複雑になるため、全体アーキテクチャ設計とプロジェクト管理が重要になります。
まとめ｜レガシーマイグレーションは『5 ステップを丁寧に＋対象範囲に合った予算』で進める
レガシーマイグレーションの成否は、『進め方の 5 ステップを丁寧に実行できるか』『対象システムの規模に合った予算・期間を確保できるか』『稼働後の定着化までを含めて計画できるか』 に大きく左右されます。コスト削減だけを目的にせず、業務継続性・業務改革・運用負荷軽減の複数価値で評価することが重要です。
- 5 ステップ：① 現状アセスメント → ② 移行戦略策定 → ③ ベンダー選定 → ④ 移行実行 → ⑤ 運用最適化
- 規模別予算（当社想定）：小規模 3,000 万～8,000 万円／中規模 5,000 万～1.5 億円／大規模 1 億～3 億円（対象サブシステム数・画面数・帳票数で大きく変動）
- 実質総費用は 当社経験上の目安としてベンダー支払額の 1.3～1.5 倍程度（社内工数・並行稼働の重複コスト含む）
- 5 大失敗パターン：① アセスメント省略 ② 手法先決め ③ 並行稼働短縮 ④ 定着化フォロー無し ⑤ 1 手法統一
- 意思決定の順序：現状把握 → 手法選定（サブシステム単位で組み合わせ）→ ベンダー選定
株式会社クオンツでは、『現状アセスメント支援』『移行戦略策定』『ベンダー選定支援』『5 年 TCO 試算』『レガシーマイグレーションプロジェクト支援』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社のシステム規模・業務要件・予算感に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
