レガシーマイグレーションの手法（リホスト・リライト・リビルド）
20年以上使い続けている基幹システムについて、「作った人がもういない」「古い言語を扱える技術者が見つからない」「ハードウェアの保守が終わる」といった問題を抱える企業は少なくありません。こうした古いシステムを新しい環境へ移す取り組みを「レガシーマイグレーション」と呼びますが、その手法にはいくつかの種類があり、どれを選ぶかで費用も期間も効果も大きく変わります。
この記事では、レガシーマイグレーションの代表的な手法であるリホスト・リライト・リビルドを中心に、それぞれの特徴と向き不向き、手法の選び方、進め方の注意点を解説します。
- レガシーマイグレーションとは、古いシステムを新しい基盤・言語・構成へ移し替える取り組みです。
- リホストは基盤だけを移す、リライトは言語を書き換える、リビルドは業務から見直して作り直す手法です。
- 変える範囲が大きいほど費用・期間・リスクは増えますが、得られる効果も大きくなります。
- 手法はシステム全体で一つに決める必要はなく、機能ごとに組み合わせるのが現実的です。
目次
レガシーマイグレーションとは
レガシーマイグレーションとは、長年使われてきた古いシステム（レガシーシステム）を、現在の技術で動く新しいハードウェア・OS・プログラム言語・システム構成へ移行することです。「マイグレーション」は移行を意味します。
レガシーシステムの問題は、単に古いことではありません。仕様がわかる人がいない、改修に時間とお金がかかる、特定のベンダーにしか保守できないなど、ビジネスの変化に合わせてシステムを変えられない状態になっていることが本質的な問題です。レガシーマイグレーションは、この状態から抜け出すための手段です。
関連記事システムリプレイスとは？進め方・費用・失敗しないポイント
レガシーマイグレーションの3つの手法
手法ごとに「何を変えるか」
| 手法 | ハードウェア・OS | プログラム言語 | 業務ロジック・設計 |
|---|---|---|---|
| リホスト | 変える | 変えない | 変えない |
| リライト | 変える | 変える | 原則変えない |
| リビルド | 変える | 変える | 見直して作り直す |
リホスト：基盤だけを新しくする
リホストとは、プログラムにはほとんど手を加えず、動かしている基盤（サーバー、OS、場合によってはクラウド）だけを新しいものに移す手法です。メインフレーム（大型汎用コンピューター）上のプログラムを、互換性のあるオープン系の環境やクラウドで動かすケースが代表例です。
短期間・低コストで移行でき、業務への影響も小さいのが利点です。一方で、古い言語や複雑なプログラム構造はそのまま残るため、「改修しにくい」「技術者が少ない」という根本的な課題は解決しません。
リライト：言語を書き換える
リライトとは、COBOLなど古い言語で書かれたプログラムを、JavaやC#などの現在主流の言語に書き換える手法です。業務の処理内容（ロジック）は原則として変えずに、言語だけを置き換えます。変換ツールを使って自動変換し、人手で修正・検証するのが一般的です。
技術者を確保しやすくなる点が大きな利点ですが、自動変換したプログラムは読みにくくなりやすく、元の設計の問題も引き継ぎます。「言語は新しいが中身は古いまま」にならないよう、変換後の保守性を確認することが大切です。
リビルド：業務から見直して作り直す
リビルドとは、現行システムの機能と業務を改めて整理し、新しい設計・技術で作り直す手法です。不要になった機能を捨て、現在の業務に合った形に再構築できるため、最も効果が大きい反面、要件定義から開発・テスト・データ移行まで一通りの工程が必要になり、費用と期間も最も大きくなります。
その他の手法：リファクタリングとリプレース
このほか、外から見た動きを変えずにプログラムの内部構造を整理する「リファクタリング」や、パッケージやSaaSに置き換える「リプレース（パッケージ移行）」も選択肢になります。業務が一般的で既製品に合わせられるなら、作り直すよりリプレースの方が早い場合もあります。
手法ごとのメリット・デメリット比較
| 手法 | メリット | デメリット | 向いているケース |
|---|---|---|---|
| リホスト | 短期間・低コスト、業務影響が小さい | 古い言語・構造が残り、根本解決にならない | ハードウェアの保守期限が迫っており、まず延命したい |
| リライト | 技術者を確保しやすくなる、ロジックを継承できる | 変換後のコードが読みにくい、設計の問題を引き継ぐ | 業務ロジックは今も有効で、言語だけが課題 |
| リビルド | 業務改善と同時に行え、将来の拡張性が高い | 費用・期間が大きく、要件定義の負担が重い | 業務も大きく変わっており、機能面の不満も大きい |
上のグラフは、同じ規模のシステムを移行する場合の費用・期間の相対的なイメージです。実際の金額はプログラムの量や品質、データ量、テストの範囲によって大きく異なるため、現状調査のうえで見積もる必要があります。
手法の選び方：機能ごとに組み合わせる
レガシーマイグレーションで大切なのは、システム全体を一つの手法で移そうとしないことです。システムの中には、業務の要になっていて今後も変化が大きい機能もあれば、ほとんど使われていない機能、安定していて手を加える必要がない機能もあります。
- 使われていない機能：移行せず廃止する。利用ログや現場ヒアリングで確認する
- 安定していて変更の少ない機能：リホストやリライトで低コストに移す
- 業務の変化が大きい・不満が多い機能：リビルドで作り直す
- 一般的な業務の機能：パッケージやSaaSへのリプレースを検討する
こうした仕分けの前提として、現行システムの棚卸し（機能・プログラム・データ・連携の一覧化）が欠かせません。仕様書が残っていない場合は、プログラムやデータを解析して現状を可視化する作業から始めます。
レガシーマイグレーションの進め方
- 現状の可視化機能・プログラム・データ・外部連携を棚卸しし、利用状況を把握する
- 方針と手法の決定機能ごとに廃止・リホスト・リライト・リビルド・リプレースを振り分ける
- 移行計画段階的に移す順番、新旧並行期間、データ移行の方式を決める
- 移行・テスト新旧の出力を比較する現新比較テストで、処理結果の一致を確認する
- 切り替えと旧システム廃止本番切り替え後、一定期間の並行運用を経て旧環境を停止する
発注者が準備しておきたいこと
レガシーマイグレーションは、開発会社だけでは進められません。現行システムについて発注者側でしか用意できない情報があるためです。見積もりや計画の精度を上げるために、次のものをできる範囲で準備しておきましょう。
- 資産一覧：プログラム・画面・帳票・バッチ処理の一覧と、おおよその数
- 利用状況：部門ごとにどの機能を使っているか、使っていない機能はどれか
- 現行の出力サンプル：主要な帳票や月次処理の結果など、比較テストに使えるデータ
- 保守契約の内容：ソースコードや設計書の提供を受けられるか、現行ベンダーの協力範囲
よくある質問
- リホストとリライトはどちらを選ぶべきですか？
- ハードウェアの保守期限が迫っていて時間がない場合はリホスト、古い言語の技術者確保が課題ならリライトが候補になります。リホストで延命しつつ、並行してリライトやリビルドを計画する段階的な進め方もあります。
- 仕様書がないシステムでも移行できますか？
- 可能です。プログラムやデータベースを解析して処理内容を明らかにし、現行システムの出力結果と新システムの結果を比較して検証します。解析と検証に時間がかかるため、計画段階でその工数を見込んでおくことが大切です。
- レガシーマイグレーションにはどれくらいの期間がかかりますか？
- 手法とシステム規模によって大きく異なり、リホストなら数か月、リビルドなら1年以上かかることもあります。現状調査の結果をもとに、段階的な移行計画を立てるのが一般的です。
まとめ
レガシーマイグレーションには、基盤だけを移すリホスト、言語を書き換えるリライト、業務から見直して作り直すリビルドなどの手法があります。変える範囲が大きいほど費用もリスクも効果も大きくなるため、現状を可視化し、機能ごとに手法を組み合わせるのが現実的です。まずは現行システムの棚卸しから始めましょう。
この記事に関連するサービス
システムリプレイス
老朽化したシステムやサポートが終わるシステムを新しく置き換えます。仕様書がないシステムも、画面・データ・プログラムの解析から対応し、段階的な移行で業務を止めずに切り替えます。 サービスの詳細を見る
