移行元A-VXシステム上の既存資産を洗い出し、移行対象となる可能性のある資産について確認します。その際、各プログラムの仕様書やファイルデザイン（レコードレイアウトなど）の存在についても確認します。

なお、資産の洗い出しに当たっては、A-VX統合管理ツールの資産管理機能により、ある期間の実業務で実際に動作しているプログラムやJS、使われているファイルや表などを明確にしていく方法が確実です。

統合管理ツールを利用できない場合には、A-VX標準のユーティリティを用い、ソースライブラリファイルやJSL/PMLのメンバ一覧や、データファイル、A-VX RDBなどの資産の一覧を作成するとともに、不要資産のたな卸しも行います。

資産分析の結果に基づき、お客様が移行先システムに求める要件（機能要件、非機能要件）について、定義します。

この際、必要であれば、移行先システムで動作するプロトタイプを作成したり、いくつかの業務APを試行的に変換し、エンドユーザに操作性の違いなどを認識してもらいます。

要件定義に基づき、各要件をどのように実現するかについて、移行先ソフトウェアの選択を行ったうえで、具体的に設計します。 この設計にあたっては、たとえばA-VX COBOLで提供されていたものの、移行先システムでは提供されていないCOBOLシステムサブルーチンについて、どのような方法で代替するかなどについても設計します。

また、移行対象とはならない機能や移行先ソフトウェアでは提供されていないユーティリティ機能についても設計します。

移行先システムで新たに必要となるAPや、移行先ソフトウェアでは提供されていないユーティリティ、提供されていないCOBOLシステムサブルーチンの代替コンポーネントなどを開発します。

移行方式設計に基づき、移行先ソフトウェアで提供されているツールなどを利用し、各資産（プログラム、データなど）を変換します。

テストについては通常のシステム開発時同等に進めますが、マイグレーションでの特徴的なテスト方法として、コンペアテストというものがあります。

これは、移行元システムと移行先システム双方で、テスト対象のプログラムに同じデータを入力した場合の出力結果を比較し差異がないかを確認することで、プログラムが正しく移行（変換）できたかを確認する方法です。

• OS(Windows, A-VX)
• CPU(プロセッサ数／コア数、動作周波数、キャッシュサイズ)
• メインメモリサイズ
• ディスク構成(搭載ディスクドライブの回転数、接続インターフェース、容量、RAID構成)

オプションボード、周辺機器、プリンタ(種別、製品名、接続形態)
導入済みA-VX有償ソフトウェア、導入済み限定対応機器
導入済みWindows用ソフトウェア(DBMS等), 導入済み追加コンポーネント(IIS等)
A-VX SGリスト（基本SG, 通信SG）

• サーバ／クライアント接続図

• 通信先(自社／他社)、回線種別、通信手順、使用ソフトウェアなど

• 手段、ツール／製品、バックアップ先、頻度、管理方法

• UPS