1つ目の検討事項は、ホスト（物理サーバ）のリソース量だ。管理者は、必要なVMの個数を見積もり、各VMをホストするために必要な物理サーバの数を計算する必要がある。アプリケーションによって必要なVMのリソース量は異なる。アプリケーションの要件に基づいて、あるVMのリソース量は他のVMよりも大きくなる可能性がある。ホストがVMに必要なリソース量を提供できるかどうかを確認する必要がある。

　インフラを設計する際は、将来必要になるリソース量を十分に備えているかどうかも重要だ。将来新しいアプリケーションの需要が発生した場合や、VMに障害が発生した場合の備えになる。VMをフェイルオーバー（待機系への切り替え）できるよう、実行中のアプリケーションに加え、他のホストの障害発生時に移行してきたアプリケーションを処理するのに十分なリソース量を備えたホストが必要だ。

2．VMを実行するための手段

　2つ目の検討事項は、Microsoftのハイパーバイザー「Hyper-V」やBroadcomの「VMware ESXi」などを含めて、どのハイパーバイザーを使うかを決めることだ。何台のホストをクラスタ化（VMのリソースとして協調動作させること）するのかを検討する必要もある。

　クラウドサービスでVMを利用することもできる。クラウドベンダーは、VMをマネージドサービスとして提供している。クラウドベンダーは、ユーザー企業に代わってホストの管理やアップデート作業を代行する。ユーザー企業はハードウェア管理の必要がなくなるため、VMの管理に集中できる。VMはクラウドベンダーのデータセンターで稼働するので、自社データセンターの電力を消費しない。

　クラウドサービスにもデメリットはある。1つ目のデメリットは、クラウドサービスではVMを完全に制御できないことだ。VMの細かい制御が必要な場合や、クラウドサービスではVMの要件を満たせない場合は、オンプレミスサーバを選ぶ必要がある。2つ目のデメリットは、用途によってはクラウドサービスの方がオンプレミスサーバでVMをホストするよりもコストが高くつくことだ。ただし逆のケースもある。

3．サーバ統合にかかるコスト

　サーバ統合プロジェクトに必要なコストに注意を払う必要がある。ハイパーバイザーのライセンスだけでなく、VMの管理・監視ツールや容量管理ツールが必要な場合がある。選択した仮想化製品やサービスによっては、サポートサービスの契約が必要になる場合もある。

4．移行方法

　最後にアプリケーションをVMに移行する方法を検討する必要がある。アプリケーションごとに差異はあるが、基本的にはサービスの中断を避ける必要がある。

サーバ統合の手法

　サーバ統合の手法は、サーバ統合の方法や実行するアプリケーションによって異なる。オンプレミスインフラで統合するのか、またはクラウドサービスに移行するのかによっても異なる。

　サーバ統合で主に使われるツールは、クラウドサービスとオンプレミスインフラを統合的に運用できるツールと、災害復旧（DR）のためのツールだ。クラウドベンダーは、オンプレミスインフラで実行中のアプリケーションをクラウドサービスに移行するための運用ツールを提供している。VMのプロビジョニング（配備）を自動化するデータベース移行ツールやアプリケーション変換ツールを提供するベンダーもある。

　DRツールは、物理サーバのアプリケーションをバックアップし、移行先の物理サーバもしくはVMにバックアップデータをリストア（復旧）する。DRツールで移行先のサーバにアプリケーションのフェイルオーバーを実行することで、ダウンタイムなしで移行できる場合もある。