レガシーシステム移行の3つの手法：リホスト・リライト・リビルドの違いと選び方
レガシーシステム移行を検討する際、手法の選択を誤ると「移行は完了したが、3年後に同じ問題が再発した」という事態になりかねません。移行には複数のアプローチがあり、それぞれ費用・期間・移行後の柔軟性が大きく異なります。
本記事では、代表的な3つのマイグレーション手法の特徴・向き不向き・費用感を整理します。
レガシーシステム移行とは何か？
レガシーシステム移行とは、老朽化・複雑化したシステムを、現在のビジネス要件に対応できる状態へ移行するプロセス全体を指します。「移行＝新システムへの全面刷新」と捉えられることがありますが、実際には目的・予算・リスク許容度に応じて、複数の手法が存在します。
大きく分類すると、以下の3つのアプローチに整理できます。
■ リホスト：既存のシステムを、別の環境（クラウドなど）へそのまま移す
■ リライト：既存の業務ロジックを維持しながら、コードや技術基盤を書き直す
■ リビルド：業務要件を再定義し、システムをゼロから再設計・再構築する
どの手法が「正解」かは、自社のシステム状態・組織の制約・移行後に何を実現したいかによって決まります。
※関連記事：基幹システムのレガシー脱却とは？放置リスク・進め方・刷新手法をやさしく解説
リホスト：最短・低コストで環境を移す
リホストとは
リホストは、既存システムのコードや構造をほぼ変えずに、動作する環境だけを移し替える手法です。オンプレミスのサーバーをクラウド上の仮想マシンへ移行するケースが代表的です。「リフト＆シフト」と呼ばれることもあります。
技術的な再設計を行わないため、移行期間が短く、費用も3手法のなかで最も抑えられます。
向いているケース
■ サーバーの老朽化やコスト削減が主な目的である
■ 既存システムの業務ロジックに大きな問題がなく、現状のまま継続したい ■ 移行期間を短縮したい、または予算に制約がある
■ まず環境を安定させてから、改善を段階的に行う方針をとっている
限界と注意点
リホストはあくまで「環境の移行」であり、システム内部の技術的負債はそのまま引き継がれます。コードの複雑性や属人化の問題は解消されないため、移行後も保守コストが高止まりするリスクがあります。
また、クラウドネイティブの機能（オートスケーリング、マネージドサービスとの連携など）を十分に活用できないケースも多く、長期的な拡張性には限界があります。
費用感
3手法のなかで最も費用を抑えやすい手法です。ただし、移行後に追加改修が必要になるケースもあるため、初期費用だけでなく移行後の保守コストも含めて試算することが重要です。
リライト：コードを書き直し、保守性を高める
リライトとは
リライトは、既存システムの業務ロジックや仕様を維持しながら、コードや技術基盤を現代の標準に合わせて書き直す手法です。「何をするか」は変えず、「どのように実現するか」を刷新します。
ブラックボックス化したコードを整理し、ドキュメントを整備し直す作業も並行して行われるため、移行後の保守性が大幅に向上します。
向いているケース
■ 業務ロジック自体は正確で変更の必要がないが、コードが複雑化・属人化している
■ 特定の技術者しか触れないシステムを、チーム全体で保守できる状態にしたい
■ 新しいシステムや外部サービスとの連携を将来的に見据えている
■ リビルドほどの予算・期間は確保できないが、現状維持では限界がある
限界と注意点
業務仕様の調査・整理に想定以上の工数がかかるケースがあります。特に、設計書が実態と乖離していたり、仕様が口頭伝承でしか残っていないシステムでは、書き直しの前段階として現行仕様の棚卸しが必要になります。
また、リライトの過程で既存の業務ロジックを誤って変更するリスクがあるため、テスト工程の設計が移行の品質を大きく左右します。
費用感
リホストよりも費用・期間ともに大きくなります。ただし、リビルドと比較すると業務要件の再設計が不要な分、工数を抑えやすい傾向があります。移行後の保守コスト削減効果が見込めるため、中長期で見たときの費用対効果を試算することを推奨します。
リビルド：ゼロから再設計し、最大の柔軟性を得る
リビルドとは
リビルドは、既存システムの構造・コードにとらわれず、業務要件を再定義したうえでシステムをゼロから設計・開発する手法です。現行システムは参照資料として活用しつつ、新しい技術スタックと設計思想で構築します。
3手法のなかで最も大規模な投資が必要ですが、移行後の拡張性・連携性・保守性はいずれも最も高くなります。
向いているケース
■ 現行システムの業務ロジック自体が現在のビジネスモデルに合っておらず、根本から見直す必要がある
■ 新技術（生成AI、クラウドネイティブアーキテクチャ等）との深い統合を前提とした設計が必要である
■ 中長期でのスケールアップや新規事業展開を視野に入れている
■ 現行システムの改修コストがすでに高止まりしており、維持継続のコストが新規構築コストに近づいている
限界と注意点
開発期間中は現行システムとの並行運用が必要になるため、運用コストが一時的に増加します。また、要件定義の精度がプロジェクト全体の品質に直結するため、業務側と技術側が緊密に連携できる体制が前提条件となります。
スコープが広がりやすい性質もあるため、フェーズ分割と優先順位の管理が重要です。
費用感
3手法のなかで最も費用・期間ともに大きくなります。リホストと比較すると数倍規模の投資になるケースも珍しくありません。ただし、移行後の保守コスト削減・事業拡張への対応力を加味した場合、長期的な総コストでは優位になることもあります。
自社に合った手法を選ぶ判断フロー
どの手法を選ぶべきか迷う場合、以下の順序で判断すると整理しやすくなります。
まず、現行システムの業務ロジックに問題があるかを確認します。「現行の業務フロー・処理内容は正確で、今後も継続して使える」と判断できる場合は、リビルドの必要はありません。
次に、コードの保守性に問題があるかを確認します。特定の担当者しか触れない、設計書が実態と乖離している、新しいシステムとの連携が難しいといった状態であれば、リライトが有力な選択肢になります。
業務ロジックにもコードにも大きな問題がなく、主な課題がサーバーの老朽化やインフラコストであれば、リホストが最も効率的な手法です。
一方、現行の業務モデル自体を変える必要がある、または中長期での抜本的な拡張を前提としている場合は、リビルドを選択する根拠になります。初期投資は大きくなりますが、移行後の制約を最小化できます。
いずれの手法においても、「移行中の並行運用をどう設計するか」と「移行後の保守体制をどう確保するか」は、手法選択と同等に重要な検討事項です。
よくある質問
Q1. レガシーシステム移行の手法にはどんな種類がありますか？
A1: 代表的なマイグレーション手法は3つです。
リホスト（環境のみ移行）、リライト（業務ロジックを維持しながらコードを書き直す）、リビルド（ゼロから再設計）があります。費用・期間・移行後の拡張性がそれぞれ異なり、自社のシステム状態と目的に応じて選択します。
Q2. リホストとリビルドの違いは何ですか？
A2: リホストは既存のコードや構造をほぼ変えずに動作環境だけを移す手法で、費用・期間ともに最も抑えられます。リビルドは業務要件から再定義してシステムをゼロから構築する手法で、移行後の拡張性は最も高くなります。技術的負債の解消を目的とする場合、リホストでは根本的な解決にならない点に注意が必要です。
Q3. レガシーシステム移行の費用はどのくらいかかりますか？
A3: 手法によって大きく異なります。リホストが最も費用を抑えやすく、リライトはその中間、リビルドはリホストと比較して数倍規模になるケースもあります。いずれも初期費用だけでなく、移行後の保守コストを含めた総費用で比較することが重要です。
まとめ
レガシーシステム移行の手法は、「コストが安いから」ではなく「自社のシステム状態と移行後の目的」で選ぶことが重要です。リホスト・リライト・リビルドはそれぞれ異なるトレードオフを持ち、どれが優れているかではなく、どれが自社の状況に適しているかが判断基準になります。
まず現行システムの課題を整理し、移行後に何を実現したいかを明確にすることが、手法選択の出発点です。
※レガシーシステムが抱える課題の詳細については、レガシーシステムが成長を阻む4つのサインもあわせてご参照ください。
