サードパーティーコンポーネントは、.NET版が存在する場合、以下のように対応します。
VB(ActiveX)版と.NET版のAPIが全く同一である場合は、中間クラスは必要ありません。変換後、参照を.NETのライブラリに変更することで変換は完了します。APIが変更されている場合は、新しいAPIを呼び出すための処理を中間クラスで行います。APIが大きく異なる場合は、この中間クラスの開発に工数が掛かることになります。
Windows Server 2003で利用されているアプリケーションの場合、データベースは多くの場合SQL ServerかOracleです。データベースの接続ドライバーは、ADOかoo4oが利用されています。ADO/oo4o共にADO.NETへ移行する必要があります。
ADOからADO.NETへ移行する場合、問題点があります。ADO.NETではADOでサポートされていたいくつかの機能が廃止されています。特に結果セットに対する機能が、多く廃止されているため、これらの機能を使っている場合は、補完するコードを開発する必要があります。
Oracleを利用している場合は、マイクロソフトが提供するADOドライバーか、oo4oを利用しているケースがありますが、共にODP.NETへ移行することが必要です。
これらのデータベースへアクセスする部分は、サードパーティーコンポーネントと同じ方法で移行することが可能です。
マイグレーションツールについては、選択のポイントがいくつかあります。移行後の体制やシステムのメンテナンスの状況、サードパーティーコンポーネントなどの利用について確認して、選択する必要があります。
VBのエンジニアが見やすいようなコードを出力するものと、.NETの作法に近いコードを出力するものがあります。前者の場合、元のコードを並べてみると対応する行が分かりやすいですが、後者の場合は、どの行がどの行に当たるのかを見分けるのが少し難しくなります。
また、移行後のメンテナンスを行うエンジニアが引き続きVBのシステムをメンテナンスしてきたエンジニアである場合は、前者の方が適していますが、VBのエンジニアはかなり減ってきているので、アサインが難しいことがあります。移行後のシステムは、.NET系のエンジニアであれば後者の方が適しています。
コード変換ツールがランタイムライブラリを持っており、変換後のコードがこのランタイムライブラリを利用するケースがあります。この場合、ランタイムライブラリのサポート期間、ランタイムライブラリに問題が起きたときのサポートなどを確認しておく必要があります。
逆に全てをソースコードに変換するツールもあります。
コード変換ツールがサードパーティーコンポーネントの中間クラスを持っている場合があります。また、マイグレーションサービスを実施している会社が提供する場合もあります。中間クラスを開発する場合は、工数や期間がかかるので確認が必要です。
最後にテストについて触れておきます。テストは新規開発と同様に行うことが必要です。ただし、冗長なコードが多い場合、それらを一つの共通部分にまとめることによって、効率化することが可能です。
コード変換ツールの中には、冗長な部分を見つけるような機能を持っているものがあります。これを利用して、分散している共通関数などを一つのライブラリにまとめることが可能です。これにより、ライブラリ部分のテストは1回で済むことになります。
また、旧システムと同じ動きであることを確認するために新旧の比較テストも必要となります。
Windows Server 2003で動作するアプリケーションを新しいWindows Serverに移行する方法の一つであるコード変換ツールを使ったマイグレーションの詳細について解説しました。
VB/ASPから.NETへの移行は、言語の性質上自動的に行えるものではないことを理解していただけたと思います。しかし、移行するためのプロセスを理解し、対象のシステムの構成を分析し、適しているものであれば、再開発に比べて半分以下のコストで移行することも可能です。
コード変換ツールを使ったマイグレーションをWindows Server 2003から移行する方法の一つとして検討してみてはいかがでしょうか。
ベンチャー企業の立ち上げを数社行い、現オン・デマンド・ワン株式会社代表取締役、米国、GreatMigrations社のgmStduioの日本での総代理店をするなど、海外からの技術導入を積極的に行っている。
Copyright © ITmedia, Inc. All Rights Reserved.