翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ステップ 5. カットオーバー
<a name="step5"></a>

一般的なリホスト移行の最後のステップは、カットオーバー期間をスケジュールし、カットオーバーをサポートするためのリソースを準備することです。

## レプリケーションステータスを検証する
<a name="5-verify-replication"></a>

 まず、レプリケーションのステータスを確認し、特定のウェーブ内のすべてのサーバーのステータスが正常であることを確認する必要があります。

[ステップ 3](step3.md) と同様に、クラウド移行ファクトリースクリプトを実行してこのステップを自動化できます。このスクリプトは、指定したウェーブ内のすべてのサーバーのステータスが「正常」に変わるまで 5 分ごとに再試行し、クラウド移行ファクトリーデータベースのレプリケーションステータスを更新します。

詳細な手順については、「クラウド移行ファクトリー実装ガイド」の「[レプリケーションステータスの検証](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#verify-the-replication-status)」を参照してください。

## カットオーバーに備えてソースサーバーをシャットダウンします。
<a name="5-shutdown"></a>

 ソースサーバーのレプリケーションステータスを確認したら、ソースサーバーをシャットダウンして、クライアントアプリケーションからサーバーへのトランザクションを停止する準備が整います。通常、カットオーバーウィンドウでソースサーバーをシャットダウンできます。ソースサーバーを手動でシャットダウンすると、サーバーごとに 5 分かかることがあり、大きなウェーブの場合、合計で数時間かかる場合があります。代わりに、クラウド移行ファクトリーのオートメーションスクリプトを実行して、特定ウェーブ内のすべてのサーバーをシャットダウンできます。

詳細な手順については、「クラウド移行ファクトリー実装ガイド」の「[対象範囲内のソースサーバーのシャットダウン](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#shut-down-the-in-scope-source-servers)」を参照してください。

## ターゲットの EC2 インスタンスを起動してカットオーバーする
<a name="5-launch-ec2"></a>

 ソースサーバーをシャットダウンしたら、ターゲット EC2 サーバーインスタンスを起動できます。[ステップ 4](step4.md) と同様に、[**サーバーを起動**] ボタンを 1 回押すだけで、指定したウェーブ内のすべてのサーバーをカットオーバーモードで起動できます。唯一の違いは、起動タイプとして「**カットオーバー**」を選択する点です。起動テストと同様に、「**Launch servers (サーバーを起動) **」ボタンは次のプロセスを自動化します。
+ レプリケーションのステータスを確認し、遅延時間が 180 分未満であることを確認します。
+ クラウド移行ファクトリーデータベースのメタデータを使用して、特定のウェーブ内のすべてのサーバーの Amazon EC2 起動テンプレートを更新します。
+ すべてのサーバーを Application Migration Service のジョブに送り、カットオーバーモードで起動します。

詳細な手順については、「クラウド移行ファクトリー実装ガイド」の「[カットオーバー用インスタンスの起動](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#launch-instances-for-cutover)」を参照してください。

## インスタンスの起動ステータスを確認する
<a name="5-status-check"></a>

 カットオーバーモードでインスタンスを起動したら、15 分以上待ってから、次のステップであるインスタンスの起動ステータスを確認します。カットオーバー起動が完了したら、クラウド移行ファクトリーオートメーションスクリプトを実行して、特定のウェーブ内のすべてのマシンの 2/2 ステータスを確認できます。

インスタンスが 2/2 のステータスチェックに失敗した場合は、「[AWS サポート](https://aws.amazon.com/premiumsupport/) 」に連絡してください。

詳細な手順については、「クラウド移行ファクトリー実装ガイド」の「[ターゲットインスタンスのステータスの検証](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-factory-web-console.html#verify-the-target-instance-status)」を参照してください。

## (オプション) ターゲットインスタンスの新しい IP アドレスを取得する
<a name="5-get-ip"></a>

 ターゲットサーバーインスタンスが新しい IP アドレスを使用する場合、次のステップは DNS サーバーを新しい IP アドレスで更新することです。シナリオによっては、ターゲットインスタンスが動的 DNS 登録をサポートし、新しい IP アドレスを DNS サーバーに自動的に登録します。たとえば、Windows サーバーが DNS サーバーとしてドメインコントローラーを使用する場合、DNS 登録は自動的に行われる可能性があります。一方、DNS の更新が手動で行われる場合は、すべてのターゲットインスタンスの新しい IP アドレスを取得する必要があります。この場合、クラウド移行ファクトリーオートメーションスクリプトを使用して、特定のウェーブ内のすべてのインスタンスの新しい IP アドレスを CSV ファイルにエクスポートできます。

詳細な手順については、「クラウド移行ファクトリー実装ガイド」の「[ターゲットインスタンス IP の取得](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-command-prompt.html#retrieve-the-target-instance-ip)」を参照してください。

## ターゲットサーバーへの RDP/SSH アクセスをテストします。
<a name="5-test-rdp"></a>

 DNS レコードを更新したら、ホスト名を使用してターゲットインスタンスに接続できます。このステップでは、リモートデスクトッププロトコル (Remote Desktop Protocol・RDP) を使用するか、Secure Shell (SSH) アクセスを使用してオペレーティングシステムにログインできるかどうかを確認します。各サーバーに個別に手動でログインできますが、クラウド移行ファクトリーオートメーションスクリプトを使用してサーバー接続をテストする方が効率的です。

詳細な手順については、「クラウド移行ファクトリー実装ガイド」の「[ターゲットサーバー接続の検証](https://docs.aws.amazon.com/solutions/latest/cloud-migration-factory-on-aws/list-of-automated-migration-activities-using-command-prompt.html#verify-the-target-server-connections)」を参照してください。

## アプリケーションとネットワークの設定を再構成する
<a name="5-config-app"></a>

 移行チームがオペレーティングシステムレベルのテストを完了すると、アプリケーションチームはアプリケーションレベルで変更を加えます。これには、以下のような変更が含まれます。
+ アプリケーションにロードバランサーが必要な場合は、ロードバランサー内のアプリケーションエンドポイントが、 AWS内の新しいインスタンス IP を指すように変更します。
+ アプリケーションウェブ層の接続文字列を変更して、データベースに接続します。
+ その他のアプリケーション固有の設定を変更します。

## アプリケーションをテストする
<a name="5-test-app"></a>

 前のセクションで説明したアップデートの後に行われるアプリケーションテストは、通常、アプリケーション所有者またはサポートチームが担当します。新しいサーバーにログインして、アプリケーションが想定どおりに動作することを確認します。動作しない場合は、アプリケーション所有者またはサポートチームが移行チームと協力して問題のトラブルシューティングと修正を行います。

## カットオーバーの完了
<a name="5-complete-cutover"></a>

 これが移行の最後のステップです。アプリケーション所有者は、 のターゲットアプリケーションが機能とパフォーマンスの両方の観点から期待 AWS を満たしているかどうかを決定します。ロールバックが必要な場合、通常は次のアクティビティが必要です。
+ 影響を受けるアプリケーションのすべての AWS インスタンスを終了する。
+ 指定されたアプリケーションのオンプレミスサーバーを有効にします。
+ DNS レコードを古いサーバーの IP アドレスに戻します。