多くの場合、ハイブリッドクラウドでは、パブリッククラウドに既存のVMサーバ群を移行させること、と新しい社内設定をすること、またはその両方が必要になる。仮想化ではハードウェアが大幅に抽象化されるが、それには幾つか変化が伴う。例えば、コンピューティング用インスタンスではメモリに違いがある。利用可能なSSDの量が増え、パフォーマンスが上がる。LANの帯域幅も広がる場合が多い。

　パブリッククラウドの基盤は、インスタンスの種類を広げるため、ベンダーが絶えず進化させている。インスタンスを最適化し、同時にコストも最適化するために、サンドボックス環境を使用するとよいだろう。これにより、ハイブリッドクラウドの初期導入のサイズとバランスを適切にすることができる。

2．データ移行

　次のステップは、データの移行だ。不要なファイルを削除し、データ配置（デプロイ）時にどこにあるデータセットを使うか計画する。一部は社内限定にし、一部はパブリッククラウドに置く。残りはクラウドの境界を行き来する。ガバナンスとコンプライアンスのソフトウェアを使用して、この決定を検証し、時間を節約する。

　実際の移行では、ITチームは一般的に次のいずれかのステップを実行する。

段階的アプローチ

　トリクル方式とも呼ばれる。このアプローチは段階的に実施し、多くの場合、シャットダウンを伴わない。ただし、全てのデータを同期するアプリケーションが必要になり、テストの観点では難しさが増す。この移行アプローチを選択するITチームは、運用と平行した追加テストの実行が必要になる可能性がある。

ビッグバンアプローチ

　全てのデータを再配置する方式。1日か2日のダウンタイムが必要になる。段階的アプローチと比べて技術的な複雑さは緩和される。だが、再起動までの時間との戦いになり、精神的な負担が大きい。

　運用チームは、ネットワーク構造やストレージなどの運用環境の移行だけでなく、アプリケーションの移行もしなければならない。ほとんどの場合、クラウドでのアプリケーションの実行は従来の環境での実行と変わらない。だが、ブロックストレージからオブジェクトストレージへの移行や、バージョンのアップデートで変更が発生し、複雑になる可能性がある。移行プロセス中は、アプリケーションに一切変更を加えてはならない。ここで変更を加えると、不具合検証（デバッグ）に絡んで問題が発生したり、そのアプリケーションが新しいパブリッククラウド基盤でしか使えなくなったりする恐れがある。

3．ネットワークとクラウドバースティングの設定

　もう1つの課題は、パブリッククラウドで仮想ネットワークを設定するためのスクリプトの作成だ。Microsoftの「Azure Stack」のような特定のハイブリッドクラウド基盤ではこのプロセスはスムーズに実施できる。だが、一般的にはこのプロセスは複雑になる。ただし「OpenStack Heat」やAmazon Web Services（AWS）の「CloudFormation」など、こうしたスクリプトを変換するツールが登場し、業界は相互運用を標準化する方向に近づいている。

　ハイブリッドクラウドネットワークでは、多くの場合、クラウドバースティングが企業にとっての最優先事項になる。ただし、ハイブリッドクラウドのPoCでこの機能を組み込む前に、サンドボックスで事前にテストしておくことだ。クラウドバースティングにはさまざまなモデルがある。パブリッククラウドの専用インスタンスが必要なモデルもあれば、オンデマンドでインスタンスを使用するモデルもある。バースト時のパブリッククラウドのコストを完全に最適化できるよう、慎重に考え、クラウトバースティング実行後のことに目を向けるようにする。

4．回復性のテスト

　最後に、ハイブリッドクラウドのPoCが正しく実行されているように思えたら、回復性とフェイルオーバー（冗長構成への切り替え）のプロセスをテストする必要がある。回復性とは、オーケストレーション（設定の自動化）によって、端末（ノード）が仮に失われても運用を続行できるコンピューティングクラスタの機能だ。一方、フェイルオーバーは、クラウドの可用性ゾーンが数時間にわたってダウンするなど、より深刻な状況で行われる。

　ハイブリッドクラウドの導入を成功させるには、この2つのプロセスをテストすることが不可欠だ。結局、設定する回復性の標準に応じて成功が左右され、スナップショットの配置方法やデータセットのレプリケート（複製）方法に影響を及ぼすことになる。

　この移行フェーズには、IT予算やスケジュールに余裕のない場合が多い。だが、それに屈しないようにする。フェイルオーバーは複数回テストすることが重要だ。