レガシーマイグレーションという言葉を聞いたことはあるだろうか。

レガシーの対義語はオープンであるが、このオープンが本格的に登場してきた1990年代後半から世の中に広く知れ渡る様になった。しかし、当初は様々な理由がありそれほど大きな市場にはならなかったが、ここ数年、レガシーマイグレーション市場は急速に拡大し、世の中にも認知されてきたと考えている。

今回、この古くて新しいレガシーマイグレーションについてご紹介したい。

レガシーマイグレーションの歴史

1990年代前半から、「ダウンサイジング」という名の基に、オープン化の波が押し寄せてきた。その中では、OSはWindowsやUNIX、データベースはOracleに代表されるRDBMS、Javaテクノロジの進化やJ2EEアプリケーションサーバの登場など、現在では当たり前になってきた技術が登場してきた。

それに合わせる様に、2000年前後からレガシーマイグレーションが本格的に登場した。黎明期を経て、2000年代後半からは、事例数、及び対象規模も大きく飛躍し、現在は成長期と言ってよい状況である。これら飛躍の要因は、景況感、（新技術に対する）レガシーシステムの拡張性の限界、技術者の激減、などの外因が主たるものであるが、レガシーの概念にWindowsやUNIXの旧バージョンが含まれているものがある事にも注目したい。

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

レガシーマイグレーションと言っても、手法は大きく3つある。

• リホスト
  COBOLなどで開発された既存アプリケーションに変更は加えず、ハードウェアプラットフォームを移行する手法。具体的にはメインフレームで動く様々なプログラムを、UNIXサーバーやWindows搭載サーバーで仮想レイヤー（ミドルウェア）によって動作をさせている。移行リスクが最も小さく、且つ移行コストも小さいが、レガシー構造は変わらない。
• リライト
  ロジックは従来のままオープン系のプログラミング言語でアプリケーションのソースコードを書き直す手法。移行リスクは他の2手法に比べ中レベルで、移行コストも中レベルとなる。
• リビルド
  システムのロジックのレベルから構築し直す方式であり、多くの場合BPRを伴う手法。実質的には、システム再構築と呼ぶ場合もある。移行リスクも最も高く、移行コストも最も高い。

レガシーマイグレーション手法の選択ポイント

最近、20社ほどのマイグレーションベンダと打合せを持つ機会があり、マイグレーションに関する手法について、具体的にディスカッションを行っている。実は多くの企業が求めている手法はリライトであり4GLからオブジェクト指向型言語への書き換えである。ここではリライトの手法選択について、一般の媒体では載っていない、そこで得た手法選択のポイントを2つ紹介したい。

(1)リライト時のプログラム構造
上記に述べたリライトだが、4GLの手続き型言語からオープンなオブジェクト指向型言語に変更する際は、マイグレーションベンダがどの様なプログラム構造を想定しているかに違いがある。単純にそのままの構造での移行、3層構造（画面、ビジネスロジック、DBアクセス）での移行、3層構造＋共有コンポーネント化をした移行である。

ユーザとしては、最低限、3層構造での移行が出来ないと、後の保守開発での効率が大きく落ちてしまうことに注意が必要。

(2)リライト時の手法
リライトを行うにあたり、ノウハウを多くためているベンダはプログラミング言語の書き換えに変換ツールを準備している。一方、ノウハウが少ないベンダは、現状分析から変換ツール仕様をデザインする、或いは変換ツールではなくスクラッチ開発を行うケースもある。しかし、変換ツール仕様を新規にデザインする会社は、技術力が高い傾向があり、レガシー環境が特殊な場合（つまり、希少プログラミング言語の場合）はマッチする可能性もある。

ユーザとしては、ベンダがどの様な手法を取っても構わないと思うが、マイグレーションの実現性とコストを見極めるために、ベンダ選定時には異なる手法を取るベンダを比較検討しておくべきであろう。