Windows Server 2003で運用中のアプリケーションが、米Microsoftの当時の主要なアプリケーションプラットフォームとテクノロジーに基づいて開発されたものであれば、Windows Server 2012 R2が備える後方互換性を用いて、最新のアプリケーションプラットフォーム環境でもコードの大規模な修正なしで移行できる場合がある。

　Windows Server 2003のアプリケーションプラットフォームといえば、当時は.NET Framework 2.0、インターネットインフォメーションサービス（IIS）6.0、ASP.NET 2.0が主流であり、さらに古いアプリケーションはASP.NET 1.1やActive Server Pages（Classic ASP）で動いているものもあるだろう。Windows Server 2012 R2のアプリケーションプラットフォームとはバージョンの差が大きい。しかしながら、Windows Server 2012 R2は、最新の.NET Framework 4.5に加えて、.NET Framework 3.5（.NET Framework 2.0の機能を含む）やClassic ASPをサポートしているため、ASP.NET 2.0やASPアプリケーションはそのまま移行できる可能性がある。Windows Server 2012 R2はフル64ビットOSであるが、32ビットエミュレーターであるWOW64（Windows 32 bit on Windows 64 bit）を提供するため、Windows Server 2003で動いていた32ビットアプリケーションも問題なく動作するはずだ。

　ただし、システム移行の際には、IISの設定方法や動作の変更点が影響するかもしれない。IIS 6.0では、IISの設定はメタベースに、ASP.NETの設定は構成ファイルに格納していた。IIS 8.5では、その両者が構成ファイルに格納され、その一部は統合されている。また、IIS 6.0とASP.NETは独立したパイプラインで動作していたが、IIS 8.5の既定は統合パイプラインモードである。アプリケーションを正常に動かすためには、アプリケーションプールで共通言語ランタイム（CLR）のバージョンやクラシックモードの指定が必要になるだろう。

画面1：レガシーアプリケーションを実行するために、CLRバージョンやパイプラインモードを指定する

　.NET Framework 1.1やASP.NET 1.1のアプリケーションについては、互換性が無いため、そのまま移行することは不可能である。ただし、コードレベルで互換性がある部分は少なからず存在する。コードの非互換の部分を改修することで、移行することは不可能ではない。ただし、それは時間とコストが掛かる作業である。機能が変わらないものに、コストと時間を掛けるのは無駄である。それなら、無理に移行することを考えずに、新たに開発する、あるいは既製のパッケージ製品で済ますなど、代替案を考えた方がよい。

　「Microsoft SQL Server」や他社のミドルウェア、データベース製品が絡むと、移行のプロセスはさらに複雑になる。例えば、SQL Serverの場合、「Microsoft SQL Server 2005」以降であれば、データベースのバックアップ／復元やデタッチ／アタッチの方法で最新の「Microsoft SQL Server 2014」に移行することが可能だが、「Microsoft SQL Server 2000」（2013年4月にサポート終了）の場合は、SQL Server 2005または「Microsoft SQL Server 2008」を経由しないと移行することができない。

　このように、実際の業務アプリケーションの移行は簡単にはいかないし、時間もコストも掛かる。Windows Server 2003のサポート終了対策で最も厄介な部分である。

図1：Windows Server 2012 R2のアプリケーションプラットフォームは後方互換性があるため、ASP.NET 2.0やASPアプリケーションは大きな改修なく動かせる

P2Vは移行作業が容易になるが解決策にはならない

　今では規模を問わず、仮想化技術を利用するのが当たり前の時代である。移行先の情報システムの多くは、「Hyper-V」「VMware vSphere」「Citrix XenServer」「KVM」など、ハイパーバイザーの仮想環境で動く仮想マシンになるだろう。

　レガシーシステムを仮想化環境へ移行する最も単純な方法は、P2V（Physical to Virtual）移行である。P2V移行は、物理サーバで稼働中のシステムからディスクイメージをキャプチャーして仮想マシンの仮想HDDに展開し、仮想化するテクニックである。物理ハードウェアを仮想マシンの仮想ハードウェアに入れ替え、中身はそのまま動かすというわけだ。

　ハイパーバイザーを提供するベンダー各社およびサードベンダー各社が、さまざまなP2V移行ツールを提供しており、稼働中の物理サーバを比較的簡単な方法でオンラインで仮想化できるようになっている。ただし、物理ハードウェアと仮想マシンの仮想ハードウェアは仕様が異なるため、P2V移行が必ずしも成功するとは限らない。P2V移行ツールで作成した仮想マシンが起動しない場合、それをトラブルシューティングして起動できるまで持っていくには、それなりの知識と経験が必要である。

　専用の物理ハードウェアに依存する情報システムの場合は、そもそもP2V移行による仮想化は困難である。問題となる専用の物理ハードウェアは、恐らく仮想マシンには接続できないからだ。例えば、パラレルまたはシリアルポートに接続されたラインプリンタ、専用のインタフェースで接続された機械や設備、医療器具などである。

　注意してほしいのは、Windows Server 2003ベースの物理サーバをP2V移行で仮想化しても、Windows Server 2003のサポート終了対策には、全くならないということである。P2V移行で仮想化しても、OSはサポート終了が迫るWindows Server 2003のままなのだから当然である。しかし、P2V移行により、保守期限切れが迫っているハードウェアや老朽化していつ壊れるかも分からないハードウェアからの縛りを解くことができるのは大きい。仮想マシンをホストする仮想化プラットフォームのハードウェアやストレージは最新のものを利用できるため、P2V移行を機に、以前より多くのリソースを割り当ててシステムの逼迫状況を解消したり、あるいは使用率の低いサーバに対するリソースを節約したりでき、全体のリソース使用を最大化できコスト効率が高まるというメリットもある。

図2：ハードウェアの保守期限や老朽化問題をP2V移行でひとまず解消し、仮想環境の利点を最大限に活用してソフトウェアの移行に取り組む

画面2：古いシステムの物理サーバやクライアントをP2V移行で仮想化しても、サポート終了対策にはならない

最終手段“塩漬け”は最小限の範囲で隔離した上で

　比較的簡単なところから最新OS環境やクラウド環境に移行を進め、どうしても残ってしまう部分を最小限の範囲に絞り込んだとしよう。

　お金と時間さえ掛けることができれば、最新OS環境またはクラウド環境に移行できない情報システムなどないはずだ。しかし、予算は限られているし、時間的な余裕はもうない。移行に手を着けられない部分について残る手段は、いわゆる“塩漬け”策である。

　しかし、単にそのまま放置するのは好ましくない。サポート終了でセキュリティリスクが高まる前に、物理的または仮想的に社内の運用ネットワークや外部記憶メディアから完全に隔離しておくべきである。仮想化できない部分については、システムごと物理的に別のLANセグメントに分け、隔離された端末まで出向いて利用させるか、ポート転送などでリモートデスクトップ接続など最小限のアクセスを提供する。仮想化できる場合は、仮想化テクノロジの機能を生かして、仮想ネットワークで隔離することができる。

　隔離して塩漬けした上で、そのシステムが不要になるまで使い続けるか、あるいは並行して新システムの構築に着手すればよい。

図3：サポートが終了したレガシーシステムをそのまま塩漬けして使い続ける場合は、物理的または仮想的に社内LANから完全に隔離し、リモートデスクトップ接続を中継するなど限定的なアクセスのみを提供すること