移行を完了する

実稼働への昇格または一括移行により、クラウドへのワークロードの移行が完了します。 アセットとそのすべての依存関係が昇格した後、実稼働トラフィックが再ルーティングされます。 トラフィックが再ルーティングされると、オンプレミスの資産は廃止されるため、使用を停止できます。

昇格プロセスは、ワークロードのアーキテクチャによって異なります。 ただし、いくつかの一貫した前提条件といくつかの共通のタスクが想定されます。 この記事ではそれぞれの前提条件を説明します。移行チェックリストとしてご利用ください。

ワークロード固有の考慮事項をチェックリストに追加してください。

移行期間のプレイブック

• プロモーション前の通知を送信します。 既に変更ウィンドウについて通知しましたが、プロモーションが開始されたことを知らせる通知を必要なすべての関係者に送信してください。
• リソースの検証 ステージングされたすべてのリソースが機能している状態であることを確認します。 これらのリソースには、ストレージ アカウントとネットワーク セキュリティ グループが含まれます。
• 監視を一時停止します。 ワークロードの移行中、一時的な停止が発生する可能性があります。 監視を一時停止してノイズを防ぎます。
• レプリケーションの最後の手順を実行します。 昇格方法によっては、最新のデータを処理するために最終的なレプリケーション手順を実行する必要がある場合があります。 Azure Migrate や Modernize などのツールを使用してサーバーの状態をレプリケートする場合、そのプロセスにはこのような手順が含まれます。 それ以外の場合は、アプリケーションのステージング方法に応じて、手動で手順を実行する必要があります。
• 追加リソースのハイドレート Azure Migrate や Modernize などのサーバー状態レプリケーションを使用している場合は、レプリケーション後のハイドレートの一環として Azure 仮想マシン インスタンスをデプロイする必要があります。 負荷分散規則など、以前はステージングできなかった項目が他にもある場合があります。
• ソース サーバーをオフにします。 リソースのハイドレート後もソース サーバーを使用できる場合は、移行を妨げないように、ソース サーバーをオフにします。 元に戻す必要がある場合は、移行項目をクリーンアップした後で、これらのサーバーを有効にすることができます。
• 分離テストを行います。 移行されたワークロードにユーザーを移行することなく実施できるテストを行います。 このテストでは、「Azure での移行デプロイのテスト」で説明されているプランに似たテスト 計画を使用します。
• 移行されたワークロードに移行します。 ドメイン ネーム システム、接続文字列、負荷分散、およびその他の項目を更新して、ユーザーまたはシステムがアプリケーションにアクセスしようとすると、新しい場所にアクセスできるようにします。
• 昇格テストを行います。 ビジネス テスト計画をもう一度実行して、すべてが期待どおりに動作することを確認します。
• 最終的な承認を求めます。 利害関係者に、ワークロードの最終的な続行/中止の決定を求めます。
• 監視を再開します。 無効になっている監視を有効にし、環境が許容可能な状態であることを確認します。
• 昇格が成功したことを伝えます。 昇格が完了し、今後の変更がないことをすべての必要な関係者に伝えます。

次のステップ

移行後のコストの最適化