Chopper3が言うように、かかる時間は、特定の環境に固有の変数が多すぎるため、かなりのレベルの精度でどれだけの時間がかかるかを判断できません。
ただし、環境が正常なギガビットLANで実行されている場合、ネットワークに他の大きな負荷はなく、SANまたはサーバーの移行元（大規模なバックアップなど）であり、仮想インフラストラクチャが過負荷になることはありません。 30〜80メガバイト/秒の速度でマシンを移行できる必要があります。
他のいくつかの変数は重要です-ファイルレベルのコピープロトコルを使用しているP2Vユーティリティを使用している場合、移行されるシステム内のファイルの数は重要になる可能性がありますが、ボリュームあたり数十万のファイルについて話す必要がありますそれは目立つからです。何百万もの小さなファイルを含むファイルシステムは、非常に長い時間がかかる場合があります。ソースシステムに100メガビットの接続しかない場合、転送速度は10分の1に低下します（明らかに）。ソースまたは宛先のストレージシステムが上記の転送速度を下回る速度で最高になると、それも速度が低下します。
一般に、私は通常、30メガバイト/秒の転送速度を許可し、その後、初期の球場番号を取得するために、さまざまな準備/再構成段階で約20〜30分を追加します。次に、移行されたシステムのテストにかかる時間を追加します。これは、サーバー上のアプリケーション/サービスによって大きく異なります。いくつかの移行を実行したら、計画を調整し、開始する前に、タイミングは遭遇するパフォーマンスに依存することを常に明確にします。
良い考えかもしれないもう1つのことは、移行のバックアウトにかかる時間を正確に見積もることです。これは通常比較的高速です（古いサーバーの電源を入れ直して、ほとんどの部分を起動するだけです）が、厳密な移行ウィンドウがある場合は、ドロップデッドタイムがバックアウトプランにキックオーバーする時期を知る必要があります。
既存の情報を推測または推定することができます。つまり、同じネットワークとストレージシステムを介して、同じ時刻などに、この特定のESXホスト/クラスターで以前に情報を取得したことがあります。これがリモートで近づく唯一の方法です。まあ、最初のオプションです。