サーバに移管するプロセスです。EOL(サポート終了)を迎えている場合や、サポート終了日が近づいている場合です。移管によるアップグレードには、本番サーバでサービスのダウンタイムを最小化できるメリットや、移管の実行中もウェブサイトをオンラインのまま維持できるというメリットがあります。新しいバージョンへの移管を滞りなく進めるために、いくつかの推奨事項をご紹介します。移管を始める前に、こちらのチェックリストに従って移管が可能であることを検証し、サーバに十分なリソースがあり、すべての要件を満たしていることを確認してください。バージョンを確認してください。ライセンスを比較します。サーバを新しくデプロイする場合、移管元サーバのすべてのデータをホストできるよう、同等以上の機能を備えるライセンスを注文する必要があります。有効期限以外に制限がない一時的なライセンスをリクエストすることもできます。このライセンスを取得するには、販売担当者までお問い合わせください。データの移管に十分なサーバリソースがあることを確認します。空きディスク容量をチェックします。移管元サーバには、少なくとも移管に必要な容量と同程度の空きディスク容量が必要です。倍以上のサイズの空きディスク容量が必要です。この追加容量は、移管先サーバにダンプを保存し、そこからデータを抽出するために必要になります。アドレスを移管先サーバに用意します。アドレスがそれぞれマッピングされます。アドレスが同じ数だけ存在することを確認してください。上限を引き上げる必要がある可能性があります。値に特に注意してください。移管元サーバと移管先サーバ間が通信できることを確認します。以降では、移行のために以下のポートを開く必要があります。インスタンスとして使用する場合)。接続を許可してください。Upgrades]に進みます。新しいウィンドウまたはタブにインストーラのウェブインターフェースが開きます。Components]をクリックし、移行・移管マネージャコンポーネントのチェックボックスをオンにして、[Continue]をクリックします。最終的な移管作業に適した時間帯を選びます。サーバの負荷が最も低い時間帯に移管作業を行うことをお勧めします。移管中に移管元サーバが受ける要求が少なければ少ないほど、移管が完了する時点で移管元サーバと移管先サーバのデータの整合性が高くなります。CPU、メモリ、ネットワーク帯域幅などのシステムリソースが大量に消費される可能性があります。営業時間外に移管を行うことで、サービスが停止するリスクを抑えることができます。移管の実施予定日を顧客にあらかじめ通知します。アドレスを新しい移管先サーバに変更する必要があるかもしれません。このような作業は、顧客の協力が必要になるため、あらかじめ予定を立てる必要があります。移管データを正しく移管し、移管先サーバで一貫性を保つには、以下の手順に従います。変更をより迅速に更新できるようになり、移行されたコンテンツがより早く表示されるようになります。値を引き下げることができます。1h最初の移行を実行します。Migration]に進みます。ウィザードに従い、移行プロセスを開始します。記述に従う必要があります。ドメインのメンバーである場合、移行ウィザードで移管元のホストにクレデンシャルを指定する際に、ローカル管理者グループの特権を持つローカルアカウントを使用する必要があります。移行結果を確認します。警告やエラーがあれば、調査します。(Windows)で、一般的なトラブルシューティングアプローチを確認できます。サーバで、コンテンツが頻繁に更新されるドメインをホストする場合(フォーラム、ブログ、e-コマースアプリケーションなど)、このようなドメインを一時停止すると、データの損失やルーチンの重複などを回避することができます。最終的な移行を実行します最初の移行が成功した場合は、こちらもオプションで実行できます。重大なエラーが発生した場合や、データが一部しか移管されていない場合は、移管元サーバのすべてのコンテンツを完全に移管するために、さらに移行セッションを行う必要があります。移管先サーバでサービスが起動していることを確認します。いくつかのウェブスペースとそれに関連するウェブサイト、メール、データベースを抜き出してチェックし、移管先サーバで正しく機能していることを確認します。レコードを反映させます。切り替わっていないときに、移行されたデータを移行元サーバのデータに合わせて更新することができます。一括実行:移行・移管を一括実行したい場合、特別な一括移行/移管スクリプトの使用をご検討ください。移行・移管の手動での実行:状況によっては、移行・移管を手動で実行するのが最適なアプローチとなります。移行・移管マネージャでは移管が難しいメールコンテンツやデータベースがある場合、接続速度が遅すぎて自動アプローチを完了できない場合、サーバのクラッシュ後にコンテンツを復元したい場合などがあります。)を参照してください。以下も参照してください。10:11再同期についての説明が欲しいです。Permalinkログインしてコメントを残してください。