リホスト・マイグレーションとは
- 設計書の紛失で現在のシステムの仕様が分からない
- オフコン資産(COBOL言語で開発)を使用している
- 最新のパッケージシステムでは業務運用変更が必要になり対応が出来ない
- 最新のパッケージシステムを導入するには資金面で苦しい
- 現行システムに何ら不満がなく、出来ることならそのまま運用し続けたい
現在古いシステムを運用されていて、ハードウェアの老朽化やOSのサポート期限、取扱データ量の増加等でシステムの移行、乗換を検討中の会社様、このようなことを感じていませんか?
こういったお悩みをお持ちの皆様に弊社がご提案しているのが、メインフレームで構築されたシステムをオープンプラットフォームへ移行する「リホスト・マイグレーション」です。
COBOL等のプログラムのソースコード、付随する各種簡易言語によるプログラム等には可能な限り修正を加えず、オープンシステム上に移行し、元の操作感、運用方法のまま稼働させる手法のことを指します。
なぜ「リホスト」なのか
レガシーシステムのマイグレーションを行う際に考えられる方法は大きく分けて、リホスト、リライト、リビルドの3つになります。 弊社のご提案するリホストでは、短期間かつ低コストでのマイグレーションが実現できます。
リホスト | リライト | リビルド | |
開発コスト | 低 | 中 | 高 |
開発期間 | 短期 | 中期 | 長期 |
リスク | 低 | 中 | 高 |
リホスト・マイグレーションサービス一連の流れ
ご相談、概算お見積もりは無料で承っております。まずはお気軽にご連絡ください。
レガシーシステムの移行作業にあたり、資産分析を行うと「継承不要資産」というものが必ず出てきます。
これをしっかりと洗い出し、取捨選択をきっちりしていくことによって、更なるコスト削減や、移行完了後の管理負担軽減にもつながります。
資産分析
移行元オフコンシステム上の既存資産を洗い出し、移行対象となる可能性のある資産について確認します。
その際、各プログラムの仕様書やファイルデザインの存在についても確認します。
なお、資産の洗い出しに当たっては、ある期間の実業務運用の中で、実際に動作しているプログラムやバッチ処理、使われているファイル情報(表、テーブル)などを明確にして行きます。
ソース・バッチ等の各種ライブラリーファイルのメンバ一覧や、データベースなどの資産の一覧を作成するとともに、不要資産の棚卸しも行います。
<調査対象となる主な資産>
アプリケーション資産 |
|
データ資産 |
|
その他資産 |
|
移行定義
資産分析の結果に基づき、お客様が移行先システムに求める要件(機能要件、非機能要件)について、定義します。
この際、必要であれば、移行先システムで動作するプロトタイプを作成したり、いくつかの業務APをパイロット的に変換し、お客様に操作性の違いなどを認識してもらいます。
移行方式設計
移行定義に基づき、各要件をどのように実現するかについて、移行先ソフトウェアの選択を行ったうえで、具体的に設計します。
この設計にあたっては、たとえばCOBOL-APで提供されていたものの、移行先システムでは提供されていないCOBOLシステムサブルーチンについて、どのような方法で代替するかなどについても設計します。
また、移行対象とはならない機能や移行先ソフトウェアでは提供されていないユーティリティ機能についても設計します。
移行対象外AP開発/不足ユーティリティ開発
移行先システムで新たに必要となるAPや、移行先ソフトウェアでは提供されていないユーティリティ、提供されていないCOBOLシステムサブルーチンの代替コンポーネントなどを開発します。
資産変換
移行方式設計に基づき、移行先ソフトウェアで提供されているツールなどを利用し、各資産(プログラム、データなど)を変換します。
単体テスト
テストについては通常のシステム開発時同等に進めますが、マイグレーションでの特徴的なテスト方法として、コンペアテストというものがあります。
これは、移行元システムと移行先システム双方で、テスト対象のプログラムに同じデータを入力した場合の出力結果を比較し差異がないかを確認することで、プログラムが正しく移行(変換)できたかを確認する方法です。
結合テスト
テストについてはメニューからの業務起動を実施、各処理(バッチ処理)単位での動作確認を実施します。
総合(運用)テスト
テストについては外部との通信等を実施し、正常動作を確認します。
インフラ構築作業
インフラ構築にあたっては、現状のシステム構成や外部/内部インタフェースなどについて確認します。
確認する主な項目は以下のとおりです。
サーバ構成 |
|
クライアント(PC)構成 |
|
ネットワーク構成 |
|
システム運用 |
|