メインフレームなどレガシーシステムを活用している企業が、オープンシステムへ移行するために理想的な方法はハードウェア／ソフトウェアすべてを新しいプラットフォームに置き換えるリビルド（リエンジニアリング）です。しかし、現実的には時間もコストもかかるハードルの高い作業です。より現実的な選択肢としてソフトウェアの移植作業を中心としたリライト、ツールや仮想環境を利用したリホストに注目が集まっています。その中でも移行期間や予算面で選択する企業が多いリホストを中心にシステムマイグレーションのポイントを整理していきます。
マイグレーションとその進め方
前回は、レガシーシステムにおける課題と、その解決方法となる「マイグレーション」について探ってきましたが、実際にマイグレーションを進めるには、どのような作業が必要となるのでしょうか。
メインフレームを撤廃し、稼働中の業務システムをオープンシステムやオープンプラットフォーム上のサービスに移管する場合、まず考えたいのは、既存システムのうち「本当に必要な部分はどこか」という点です。
企業にとってコアビジネスが変わらないとしても、事業体制や市場、社会環境の変化によって、あまり使わない機能、稼働していないシステムがあるはずです。使わない機能の棚卸しを行うことで、システムマイグレーションの手法によっては、費やす時間とコストを圧縮することができます。
残すシステム、残さないシステムの整理ができたら、リビルド、リライト、リホストといったマイグレーション戦略を決定します。簡単におさらいすると、リビルドはシステムをほぼ新たに構築する作業となります。もし、要件定義や仕様など流用できる部分があるなら、ソフトウェアを新しい言語で移植するリライトが選択肢に挙がるでしょう。
しかし、いずれもコスト面が問題となります。コストや時間を節約しつつ、レガシーシステムを生かしたい場合はリホストが有力な選択肢となります。
もちろん、どの戦略を採用するかは、マイグレーションするシステムの重要度（経営への貢献）、予算、時間などに依存します。最近は、移行ツール、仮想環境など、ソリューションも充実しつつあり、リホストを選択する企業が少なくありません。
リホストするサーバーについてはIaaS（Infrastructure as a Service）やPaaS（Platform as a Service）を利用すれば、さらに設計の自由度が増し、マイグレーションのためのハードウェアコストを削減することも期待できます。
マイグレーションのタイミングとスケジュール
マイグレーションを実施するタイミングですが、多くの場合、ハードウェアリースの更新時期が一つの目安になります。メインフレームや古い機器の場合は、メーカーが製造を終了したり、補修部品を含むサポートが終了したタイミングなどでも、マイグレーションを検討せざるを得なくなることがあります。
いずれの場合も、終了期限は事前に把握できるはずですので、マイグレーション作業、テスト作業を含め、余裕を持ってスケジュールを立てておくことが重要です。
リビルドやリライトは、一部の要件定義や設計までのプロセスを省略できる可能性はありますが、原則として新規開発を同じ作業工数や負荷を想定してスケジュールを考えておくべきでしょう。
一方、リホストは移行ツールがうまく適合すれば、かなり短期間でのマイグレーションが期待できます。ベンダーの中には、テスト期間も含めて数か月の移行メニューを提示している場合もあります。テストで問題が発生すればデバッグ作業は必須です。リホストとはいえ、すべて自動化できるわけではないので、とくにテストの手順、期間については注意する必要があります。
旧バージョンのWindowsやLinuxベースのシステムをマイグレーションしたい場合、古い環境をそっくり仮想化環境でラッピングすることも可能です。ラッピングで対応が可能であれば、ソフトウェアリソースはほぼそのままで仮想化マシンに移設するだけで済みます。サポートが終了したOSを使い続けたいなど、セキュリティー要件を満たさないシステムの温存に利用されるスキームですが、これも一種のリホストと言えます。
移行に必要な作業工数は、元のシステムに依存します。独自の業務プロセスに特化したもの、独自データーベースに依存するものなど作り込みの度合いが高いほど、時間がかかりますので、スケジュールについては依頼するシステムベンダー等と綿密に検討・調整する必要があります。
マイグレーションの注意点
