長年使い続けてきた基幹システムの保守期限が近づき、仕様を知る担当者も定年を迎えつつある。経営層からは刷新の方針を求められているものの、どのシステムから、どの方法で、どれくらいの期間をかけて移すべきか、判断材料がそろっていない。情報システム部門やDX推進部門では、こうした状況が珍しくありません。

この記事では、レガシーマイグレーションの基本から3つの手法の選び方、大企業が段階移行で失敗しないための手順と体制づくりまでを解説します。

この記事を読むと理解できること

• レガシーマイグレーションの意味とモダナイゼーションとの違い

• レガシーシステムを放置した場合に大企業が抱えるリスク

• レガシーマイグレーションで得られるメリットと避けられない課題

• リホスト・リライト・リビルドの違いと、システムごとの選び方

• 稟議と合意形成を含めた、大企業向けの進め方の手順

• 業務プロセスやUXを移行と同時に見直すべき理由

• 生成AIによるコード解析など、近年の効率化の選択肢

レガシーマイグレーションとは

レガシーマイグレーションとは、古い技術や基盤の上で動いている情報システムを、新しいプラットフォームや言語、アーキテクチャへ移行する取り組みのことです。「レガシー」は時代遅れになった遺産、「マイグレーション」は移行や移住を意味します。レガシーマイグレーションの対象として典型的なのは、メインフレーム上でCOBOLなどにより構築された基幹システムですが、それだけではありません。

レガシーシステムの定義

レガシーシステムとは、構築から長い年月がたち、技術・ハードウェア・運用ノウハウのいずれかが古くなって維持が難しくなったシステムを指します。メインフレームやオフコンが代表例ですが、比較的新しいオープン系のシステムであっても、度重なる改修で構造が複雑になり、仕様を説明できる人が限られていればレガシー化していると考えるべきです。

つまり、レガシーかどうかは使われている技術の古さだけで決まるわけではありません。「変更したいときに安全かつ素早く変更できるか」という観点で判断するのが実務的です。

モダナイゼーションとの違い

レガシーマイグレーションとよく並べて語られるのがモダナイゼーションです。両者の線引きは記事や企業によって多少異なりますが、一般的にはレガシーマイグレーションが「既存の仕様や業務ロジックを保ったまま、稼働環境や言語を新しくすること」に重心を置くのに対し、モダナイゼーションは「業務プロセスやシステム構造そのものを現代的に作り変えること」を含む広い概念として扱われます。

実際のプロジェクトでは、どちらか一方だけを選ぶというより、システムの重要度や将来の変化の大きさに応じて両者を組み合わせるケースが多くなります。本記事でも、移行の手法としてリビルドのような作り直しまでを含めて解説します。

レガシーマイグレーションが大企業で求められる背景

レガシーマイグレーションがここ数年で経営課題として扱われるようになった背景には、技術的な老朽化だけでなく、人材・コスト・事業スピードの問題が重なっていることがあります。特に多くの基幹システムを抱える大企業ほど、影響が大きくなりがちです。

2025年の崖が示した構造的な課題

経済産業省は2018年のDXレポートで、複雑化・ブラックボックス化した既存システムが残り続けると、2025年以降に最大で年間12兆円の経済損失が生じる可能性があると指摘しました。いわゆる「2025年の崖」です。2025年を過ぎた現在も、既存システムの維持にIT予算と人材の多くが割かれ、新しい取り組みに投資できないという構造は多くの企業で解消しきれていません。

このレポートが示したのは、期限そのものよりも、既存システムが経営の足かせになるという構造でした。期限が過ぎたから終わりではなく、自社のシステムがどの程度その構造に当てはまるかを点検し続けることが求められています。

技術者不足と属人化

メインフレームやCOBOLに精通した技術者は高齢化が進み、退職とともに暗黙知が失われていきます。設計書が残っていても実装と一致していない、あるいは改修履歴が追えないといった状態では、障害対応や法改正への対応が一部の担当者に依存し続けます。

また、保守を長年同じベンダーに委ねてきた結果、仕様を理解しているのが外部の担当者だけという状況もあります。こうしたベンダーロックインの状態は、レガシーマイグレーションの検討を始めるうえでも交渉力を弱める要因になります。詳しくはベンダーロックインの解説記事も参考にしてください。

保守コストの増大と事業スピードの低下

古いハードウェアの延長保守やサポート切れのミドルウェアへの対応には、年々コストがかかるようになります。さらに、新しいサービスと連携させるたびに個別のつなぎ込みが必要になり、事業部門が求めるスピードで機能を追加できません。クラウドやAPI連携、生成AIの活用といった新しい取り組みが、既存システムの制約によって後回しになるケースも少なくありません。

レガシーマイグレーションのメリット

レガシーマイグレーションを進めることで得られる効果は、コスト削減だけにとどまりません。大企業の視点で整理すると、主に次の4つが挙げられます。

運用・保守コストの最適化

レガシーマイグレーションによって専用ハードウェアや延長保守契約から解放され、クラウドやオープンな基盤に移すことで、運用費を利用量に応じて調整しやすくなります。保守を担える技術者の母数も多くなるため、特定の人材やベンダーへの依存によるコストの高止まりを抑えられます。

新技術との連携と拡張性の向上

API連携を前提にした構成に移行すれば、SaaSやデータ分析基盤、AIサービスとの接続が容易になります。全社展開する新しい業務アプリケーションや、グループ会社とのデータ連携を検討する際にも、既存基幹システムとの連携がボトルネックになりにくくなります。

セキュリティと安定稼働の確保

サポートが終了したOSやミドルウェアは、脆弱性が見つかっても修正プログラムが提供されません。レガシーマイグレーションによって保守の続く環境へ移すことで、セキュリティ審査で指摘されがちなリスクを解消し、ハードウェア故障による長時間停止の可能性も下げられます。

ブラックボックスの解消と資産の可視化

レガシーマイグレーションの過程では、プログラムやデータ、業務との対応関係を棚卸しすることになります。この作業自体が、どのシステムが何を担い、どれが使われていないのかを可視化する機会になります。結果として、IT資産の全体像を経営層に説明しやすくなり、将来の投資判断の精度も上がります。

レガシーマイグレーションのデメリットと課題

一方で、レガシーマイグレーションには避けて通れない負担もあります。事前に課題を把握し、計画と体制に織り込んでおくことが重要です。

現状調査とデータ移行に時間がかかる

長年の改修で複雑になったシステムのレガシーマイグレーションでは、どのプログラムがどのデータを更新しているかを調べるだけでも大きな工数がかかります。データ移行では、項目定義の違いや文字コードの変換、過去データの品質問題にも対処しなければなりません。テストや並行稼働の期間も含めると、想定より期間が延びることを前提に計画を立てるべきです。

新旧両方を理解する人材の確保

レガシーマイグレーションには、既存システムの技術と移行先の技術の両方を理解できる人材が必要です。こうした人材は社内外ともに限られており、プロジェクトの初期段階から確保しておかないと、調査や設計の段階で停滞します。

移行直後の業務負荷と現場の抵抗

画面や操作が変わると、レガシーマイグレーションの直後は現場の生産性が一時的に下がります。仕様を変えずに移したつもりでも、細かな挙動の違いや不具合が業務に影響することもあります。現場が新しいシステムを受け入れなければ、旧システム時代の手作業やExcel運用が残り続け、レガシーマイグレーションの効果が十分に得られません。

投資対効果を説明しにくい

レガシーマイグレーションは、既存の機能を維持することが主目的になる場合、売上の増加のような分かりやすい効果を示しにくい取り組みです。稟議では「何も変わらないのに多額の投資をするのか」という問いに答える必要があります。保守費の推移や障害リスク、移行しなかった場合に失う事業機会を定量・定性の両面で整理しておくことが求められます。

レガシーマイグレーションの3つの手法

レガシーマイグレーションの代表的な手法は、リホスト、リライト、リビルドの3つです。それぞれ、変える範囲とかかる工数、得られる効果が異なります。

リホスト

リホストは、レガシーマイグレーションの中でも最も変更範囲が小さく、プログラムのロジックや言語はそのままに、稼働させる基盤だけを新しい環境へ移す手法です。メインフレームからオープン系サーバーやクラウドへ移すケースが該当します。短期間・低リスクで進められる一方、ブラックボックス化した構造やCOBOL技術者への依存は残るため、時間を稼ぐための手段と位置づけるのが現実的です。

リライト

リライトは、既存の仕様や業務ロジックを保ったまま、プログラムをJavaなどの新しい言語に書き換える手法です。変換ツールを使って効率化することも多く、技術者を確保しやすい言語に移れる点が利点です。ただし、自動変換では旧来の構造がそのまま持ち込まれ、読みにくいコードが量産されることがあるため、変換後の保守性を検証する工程が欠かせません。

リビルド

リビルドは、現行の業務を見直したうえで、システムを新しく設計し直す手法です。不要な機能を削り、将来の事業変化に合わせた構造に作り変えられるため、得られる効果は最も大きくなります。その反面、要件定義からやり直すため期間とコストがかかり、関係部門との合意形成の難易度も上がります。

塩漬けや廃止も選択肢に入れる

すべてのシステムを移行する必要はありません。更改の予定が近い、利用者が限られているといったシステムは、当面そのまま使い続ける「塩漬け」や、業務ごと廃止してしまう判断もあり得ます。移行対象を絞り込むことは、レガシーマイグレーション全体の期間とコストを抑えるうえで重要な一手です。

レガシーマイグレーションの手法をシステムごとに選ぶ判断軸

大企業では、数十から数百のシステムが連携しながら動いていることも珍しくありません。全社一律の手法を決めるのではなく、システムごとに方針を決めるポートフォリオの考え方が有効です。

事業上の重要度と変化の大きさで分類する

判断の起点になるのは、そのシステムが支える業務が今後どれだけ変わるかです。競争力の源泉となり、事業の変化に合わせて頻繁に改修が必要な領域はリビルドの候補になります。反対に、会計や人事のように業務の標準化が進んでいる領域は、パッケージやSaaSへの置き換え、あるいはリホストやリライトで十分な場合があります。

技術的負債の深さと連携の複雑さを見る

同じ重要度のシステムでも、コードの品質やドキュメントの残り具合、他システムとの連携の数によって移行の難易度は大きく変わります。連携が多いシステムを先に動かすと影響範囲が広がるため、周辺の独立性が高いシステムから段階移行し、知見をためてから中核へ進む順序も検討に値します。

判断結果を一枚の地図にまとめる

重要度と難易度の2軸でシステムを配置し、それぞれの手法と移行時期を一覧にした地図をつくると、経営層や事業部門への説明が格段にしやすくなります。現状と目指す姿の整理には、As-Is/To-Beの考え方が役に立ちます。

大企業におけるレガシーマイグレーションの進め方

ここからは、大企業がレガシーマイグレーションを進める際の手順を、稟議や合意形成のプロセスも含めて整理します。

1. 目的と推進体制を決める

最初に、レガシーマイグレーションによって何を達成したいのかを経営戦略・IT戦略と結びつけて言語化します。保守期限への対応なのか、事業スピードの向上なのかによって、選ぶ手法も投資の規模も変わるためです。あわせて、情報システム部門、事業部門、経営層の代表で構成する推進体制とPMOを置き、意思決定のルートを明確にしておきます。

2. 現状を調査し資産を棚卸しする

プログラム、データ、帳票、インターフェース、運用手順を洗い出し、業務との対応関係を整理します。この棚卸しはレガシーマイグレーションの成否を左右する工程です。実際の利用状況を調べると、ほとんど使われていない機能や画面が見つかることも多く、移行対象を絞り込む材料になります。

3. 移行方針と計画を策定する

前述の判断軸をもとに、システムごとの手法と移行順序を決めます。一括で切り替えるのか、段階移行で並行稼働させるのか、データ移行をどのタイミングで行うのかを計画に落とし込み、業務を止めない前提でリスク対策を盛り込みます。

4. 稟議と合意形成を進める

投資額や期間、効果、リスクを整理し、稟議を通します。このとき、文章や図表だけで移行後の姿を説明しようとすると、関係者ごとに解釈がずれ、後工程での手戻りにつながりがちです。新しい画面や業務の流れをプロトタイプで示すと、事業部門や経営層が具体的なイメージを持ったうえで判断できます。

5. ベンダーを選定し移行を実行する

自社の方針に合う進め方ができるパートナーを選び、契約形態や役割分担を明確にしたうえで、移行・テスト・並行稼働を進めます。基幹システム全体の刷新に関わる論点は、基幹システム刷新の記事でも詳しく解説しています。

6. 定着化と継続的な改善を行う

レガシーマイグレーションによる切り替え後は、現場の問い合わせや運用上の課題を拾い上げ、改善を続けます。移行が終わった時点をゴールにせず、変更しやすい状態を維持する運用と内製の体制づくりまでを計画に含めておくことが、再びレガシー化しないための鍵です。

レガシーマイグレーションを成功させるポイント

手順どおりに進めても、レガシーマイグレーションが期待した成果につながらないケースがあります。大企業でつまずきやすい点を踏まえ、押さえておきたいポイントを紹介します。

業務プロセスとUXを同時に見直す

レガシーマイグレーションで仕様をそのまま移すことを優先しすぎると、紙やExcelを前提にした古い業務の流れや、使いにくい画面までそのまま新システムに引き継がれます。移行のタイミングは、現場の業務を見直す数少ない機会です。現場の担当者が日々どのように操作しているかを観察し、使われる画面と業務の流れを起点に再設計することで、移行直後の生産性低下や現場の抵抗も抑えやすくなります。

現場と並走して認識を合わせる

レガシーマイグレーションでは、現行システムの暗黙の仕様を知っているのは現場の担当者であることが少なくありません。会議室でのヒアリングだけで要件を固めるのではなく、プロトタイプを見せながら確認を繰り返すことで、仕様の抜け漏れや認識のずれを早い段階で発見できます。

生成AIによるコード解析を活用する

近年は、レガシーマイグレーションの現状調査において、生成AIを使って既存のソースコードを解析し、処理内容の説明や設計書の下書きを作成する取り組みが広がっています。ブラックボックス化したシステムの理解にかかる時間を短縮できる可能性がある一方、出力内容が正しいかどうかの確認は人が担う必要があります。AIに任せる作業と人が判断する作業を分けて計画に組み込むことが大切です。

特定ベンダーやパッケージありきで考えない

レガシーマイグレーションの移行先となる製品やベンダーを先に決めてしまうと、自社の業務に合わない部分をカスタマイズで埋めることになり、新たなレガシーを生みかねません。手法の判断は自社の業務と将来像を起点に行い、パッケージ、SaaS、スクラッチ開発を比較したうえで選ぶことが、ベンダーロックインを繰り返さないための前提になります。開発会社の比較検討を進める際は、システム開発会社の選び方も参考になります。

株式会社FAKEでは、構想や要件定義といった上流工程にFDEが入り、プロトタイプとヒアリングを反復しながら認識合わせと要件定義書の作成を進める支援を行っています。FDEの役割についてはFDEとは何かを解説した記事で紹介しています。

まとめ

レガシーマイグレーションは、老朽化したシステムを新しい基盤へ移すだけの作業ではなく、既存システムが経営の足かせになっている構造を解消するための取り組みです。リホスト、リライト、リビルドにはそれぞれ得意な場面があり、大企業では全社一律ではなく、システムごとの重要度と難易度に応じて手法と順序を決めることが現実的です。

進め方では、目的の言語化と推進体制づくりから始め、現状の棚卸し、移行計画、稟議と合意形成、移行実行、定着化までを一連の流れとして計画します。特に、業務プロセスとUXを同時に見直すこと、プロトタイプで関係者の認識をそろえること、ベンダーやパッケージありきで考えないことが、移行後に使われ続けるシステムにするための要点です。

レガシーマイグレーションに関するよくある質問

レガシーマイグレーションにはどれくらいの期間がかかりますか

対象システムの規模や手法によって大きく異なります。リホストであれば比較的短期間で済む一方、基幹システムをリビルドする場合は、要件定義から並行稼働までを含めて数年単位の計画になることもあります。段階移行で優先度の高い領域から着手し、早い段階で効果を示しながら進めると、関係者の理解も得やすくなります。

レガシーマイグレーションとクラウド移行は同じものですか

同じではありません。クラウド移行は移行先の選択肢の一つであり、レガシーマイグレーションの中でクラウドを採用するケースが多いという関係です。オンプレミスの新しい基盤へ移す場合や、言語を書き換えることが主目的の場合も、レガシーマイグレーションに含まれます。

COBOLで書かれたシステムは必ずJavaなどに書き換えるべきですか

レガシーマイグレーションでは、必ずしも書き換える必要はありません。安定して稼働しており、今後の改修頻度も低いシステムであれば、リホストで基盤だけを移す、あるいは当面維持するという判断もあり得ます。一方で、技術者の確保が難しくなっている場合や、頻繁な改修が見込まれる場合は、リライトやリビルドを検討する価値があります。

社内に詳しい人材がいない場合はどう進めればよいですか

まずは現状調査と方針策定の段階から外部の専門家の支援を受け、社内の担当者が一緒に判断できる体制をつくることをおすすめします。すべてを外部に任せると、移行後に再びブラックボックス化するおそれがあるため、ドキュメントの整備や知見の移転も契約の範囲に含めておくと安心です。

移行後に現場で使われないシステムにならないためには何が必要ですか

要件定義の段階から現場の担当者を巻き込み、実際の業務の流れに沿って画面や操作を確認していくことが重要です。プロトタイプを使って早い段階で触ってもらい、意見を反映するサイクルを回すと、切り替え後の混乱や手作業への逆戻りを防ぎやすくなります。