移行を計画する

移行計画では、ワークロードを Azure に移行するための特定の順序、タイミング、アプローチを定義します。 この計画では、高度な移行戦略を実用的なデプロイ シーケンスに変換します。 ワークロードの優先順位付け、移行シーケンス、データ転送方法などの戦術的な決定に対処することで、クラウド導入計画に基づいています。

前提条件:移行導入計画、 Azure ランディング ゾーン

移行の準備とスキルを評価する

準備状況の評価により、移行計画を実行するために必要なスキルとサポートがチームに確実に与えます。 この手順では、機能のギャップを特定し、対象となるトレーニングまたは外部サポートを通じて進行状況を加速します。

1. チームの Azure スキルを評価します。 Azure サービス、移行ツール、カットオーバーに関するチームのエクスペリエンスを確認します。 この評価は、特定の知識ギャップを特定し、チームが成功するために必要なトレーニングを決定するのに役立ちます。

2. 必要に応じ、外部の専門知識を活用します。 チームにクラウド移行の経験がない場合は、 Microsoft または Microsoft パートナーを導入してください。 外部の専門家は、移行戦略を検証し、適切なツールを推奨し、現実的なタイムラインを確立するのに役立ちます。 このサポートにより、リスクが軽減され、特に複雑または大規模なプロジェクトの移行が高速化されます。

データ移行パスを選択する

データ移行パスは、現在の場所から Azure にデータを移動する方法です。 適切なパスを使用すると、データ転送を安全かつ迅速かつコスト効率よく行うことができます。 まず、使用可能なネットワーク接続、ExpressRoute、VPN、またはパブリック インターネットを確認して、オプションを理解します。

1. ExpressRoute がある場合は、ExpressRoute を使用します。 ExpressRoute を使用すると、インターネット接続よりも高速で安全な Azure へのプライベートな専用接続が提供されます。 ExpressRoute が既にある場合、または取得する予定がある場合は、すべてのワークロードに対してこの方法を使用します。 ExpressRoute にはセットアップ時間が必要であり、データ転送コストがかかることに注意してください。

2. ExpressRoute を使用できない場合は VPN を使用します。 セキュリティで保護されたデータ転送が必要で ExpressRoute がない場合は、VPN を選択します。 VPN はインターネット経由で Azure への暗号化されたトンネルを作成しますが、通常は ExpressRoute よりも低速です。 開始する前に、Azure で VPN ゲートウェイが構成されていることを確認します。

3. 大量のデータには Azure Data Box を使用します。 Data Box は、大量のデータを含むオフライン移行に最適です。 Microsoft は、データをコピーする物理デバイスを発送した後、返送します。 このオプションは、ネットワークの使用を回避しますが、配送時間が原因で最も時間がかかります。

4. 機密性の低いデータにはパブリック インターネットを使用します。 このオプションは、データが暗号化を必要とせず、ExpressRoute または Data Box を使用できない場合に機能します。 この方法はどこでも利用できますが、安全性は最も低く、他のインターネット アクティビティの速度が低下する可能性があります。

移行シーケンスを決定する

移行シーケンスは、ワークロード移行の論理的な順序を確立することで、リスクを軽減し、チームの信頼度を高めます。 このシーケンスでは、最初に移動するワークロードと、依存コンポーネントを一緒に移行してサービスの中断を防ぐ方法を決定します。 大規模なポートフォリオを移行ウェーブに整理します。 ウェーブ計画の詳細なガイダンスについては、「 移行ウェーブ計画」を参照してください。

依存関係の検索

1. 最初にすべての依存関係を検出します。 ワークロード間の依存関係により、一緒に移行しないとサービスの中断が発生します。 移行グループを作成する前に、内部依存関係と外部依存関係をマップして、これらの接続を検出します。

2. 依存関係の種類と重要度を分析します。 依存関係の種類が異なると、移行方法が異なります。 次のカテゴリを区別します。

   依存関係の種類	Description	移行のアプローチ
   直接の依存関係	コンポーネント間の即時の通信と待機時間の短縮が必要です。	直接接続されているすべてのコンポーネントを一緒に移動して、パフォーマンスを維持し、中断を回避します。
   間接依存関係	システム間で不定期または重大でない対話を行います。	接続で待機時間が許容される場合、またはハイブリッド使用をサポートしている場合は、まとめて移行するか、別のウェーブで移行します。
   ビジネスの依存関係	組織または管理の関係に依存します。	関連するワークロードとレポート システムをグループ化して移行し、ビジネスの優先順位に合わせます。

3. 依存関係によってワークロードをグループ化します。 共有データベース、API、認証サービス、またはネットワーク接続に基づいてグループを作成します。 これらのグループは、移行ウェーブの基礎を形成し、機能に必要なすべてのコンポーネントが一緒に移動することを保証します。 依存関係の重要度に関する不確実性が存在する場合は、コンポーネントをグループ化します。 この保守的なアプローチは、将来の分離に柔軟性を提供します。

4. 各依存関係グループを体系的に文書化します。 一貫性のある名前付け規則を使用して、依存関係グループに基づいて資産にタグを付けます。 以下を使用して各グループを文書化します。

   • グループ名と ID - 一意の識別子とわかりやすい名前
   • コンポーネント インベントリ - すべてのインフラストラクチャ要素、アプリケーション、およびサービス
   • 重要な依存関係 - 特別な処理を必要とする重要な接続
   • 移行の制約 - ビジネス、技術、またはタイミングの要件

5. グループの完全性を検証します。 ロード バランサー、DNS レコード、キャッシュ レイヤーなどのサポート インフラストラクチャなど、アプリケーションが動作するために必要なすべてのコンポーネントが各グループに含まれていることを確認します。

分割環境での操作に対応する

1. 移動できない依存関係を計画します。 技術的または規制上の理由から、ソース環境に留まる必要があるコンポーネントを特定します。 移動できない理由、他のシステムに接続する方法、共有するデータを文書化します。 このドキュメントは、これらのコンポーネントがクラウド システムと円滑に連携するための戦略を作成するのに役立ちます。

2. 分割環境の操作時間を最小限に抑えます。 コンポーネントが後でクラウドに移行できるが、すぐには移行できない場合は、クラウド システムとの接続とデータ フローを文書化します。 タイムラインとリスク管理アプローチを使用して明確な計画を作成し、両方の環境でワークロードが動作する時間を短縮します。 より多くのコンポーネントが一緒に移動できるようになるまで、移行を遅らせることを検討してください。

3. 環境を効果的に接続します。 API ゲートウェイ、メッセージ キュー、データ同期などの統合方法を使用して、クラウド ワークロードとソース環境コンポーネントの間に信頼性の高い接続を作成します。 これらのアプローチにより、遅延が軽減され、セキュリティが向上し、最終的に残りのコンポーネントをクラウドに移動する方法が準備されます。

移行するワークロードに優先順位を付ける

1. ワークロードの詳細を確認します。 利害関係者と協力して、各ワークロードのビジネスと技術的な詳細を確認します。 ダウンタイムまたは障害への影響を十分に理解し、現在のビジネス上の優先順位と一致していることを確認します。 移行導入計画を使用して、部署、ワークロード所有者、技術的な依存関係、重要度分類などの詳細を確認します。 これらの詳細は、ワークロードの優先順位付けと順序付けを効果的に行うのに役立ちます。

   Priority	ビジネス バリュー	Effort	Description
   High	High	Low	クイックな成功 - 即時の効果を得るための優先移行
   Medium-High	High	High	戦略的投資 - 十分なリソースで慎重に計画する
   Medium-Low	Low	Low	簡単な候補 - 主要な移行間のギャップを埋める
   Low	Low	High	回避または延期 - 価値の高い機会にリソースを集中する

2. リスクを軽減するために、よりシンプルなワークロードから始めます。 より複雑でリスクの低いワークロードの移行を開始します。 このアプローチは、より困難なワークロードに取り組む前に、チームが自信を持って移行プロセスを調整するのに役立ちます。 スタンドアロン アーキテクチャと最小限の統合ポイントを使用して、内部ツール、開発環境、または使用率の低いアプリケーションをターゲットにします。

3. 本番環境の前に、開発環境やテスト環境を移動します。 非運用環境では、完全な移行プロセスをテストするための安全な領域が提供されます。 準備状況を検証するために、運用環境の前に開発、ステージング、および QA 環境を移行します。 この順序により、チームはユーザーに影響を与えることなく、構成、パフォーマンス、回復の手順をテストできます。 運用チームをトレーニングするには、非運用移行を使用します。

4. 最初の成功を示した後、重要なシステムをスケジュールします。 重要なアプリケーションは、Azure に移行する前に実証済みの移行機能を必要とします。 チームが Azure サービスとのコンピテンシーを示す場合は、これらの移行を後のウェーブで計画します。 ハードウェアの更新サイクルなどのビジネスの期限では、より多くのセーフガードとテスト期間を延長して、重要なアプリケーションの優先順位を早くする必要がある場合があります。

5. 代表的な複雑なワークロードを含め、シナリオをテストします。 ミッション クリティカルなアプリケーションで直面する課題を明らかにするために、各初期ウェーブに 1 つまたは 2 つの複雑なワークロードを追加します。 多層アプリケーションやデータベース依存システムなどの一般的なパターンを表すワークロードを選択します。

詳細な移行スケジュールを作成する

1. 移行ごとに開始日と終了日を設定します。 スムーズな実行を保証するために、テストと問題解決のためのバッファー時間を含めます。 この詳細なスケジュール設定により、遅延のリスクが軽減され、効果的なリソース計画がサポートされます。

2. タイムラインをビジネス イベントに合わせます。 財務終了、製品の発売、休暇などの重要な事業期間中に移行をスケジュールすることは避けてください。 この連携により、ビジネスの中断のリスクが軽減され、利害関係者の信頼が確保されます。

3. プロジェクト管理ツールを使用して進行状況を追跡します。 Azure DevOps などのツールを使用して、依存関係の管理、マイルストーンの追跡、変更の効果的な伝達を行います。 これらのツールは、移行の進行状況を可視化し、プロアクティブな問題の解決をサポートします。

ワークロードごとに移行方法を選択する

移行方法は、ダウンタイムを伴う移行とダウンタイムがほぼゼロの移行という 2 つのカテゴリに分類されます。 ダウンタイムの許容度とビジネスの重要度に基づいて、各ワークロードに最適な移行方法を選択します。

1. 計画的な停止を許容するワークロードのダウンタイム移行を選択します。 ダウンタイムの移行は、ソース環境とターゲット環境の間でリアルタイム同期を必要としないため、よりシンプルで高速です。 この方法は、開発環境、テスト システム、スケジュールされたメンテナンス期間のあるアプリケーションなどの重要でないワークロードに適しています。 各ワークロードの許容されるダウンタイム期間を文書化し、使用率の低い期間中に移行をスケジュールして、ビジネスへの影響を最小限に抑えます。

2. 重要なワークロードのほぼゼロダウンタイムの移行を選択します。 ダウンタイムがほぼゼロに近い移行により、継続的なデータ レプリケーションとカットオーバー手法による移行中も、重要なワークロードが動作し続けます。 この方法は、顧客向けのアプリケーション、リアルタイム トランザクション システム、または厳密なサービス レベル アグリーメントを持つワークロードに不可欠です。 ワークロード アーキテクチャで継続的レプリケーションがサポートされていること、およびネットワーク帯域幅がリアルタイムのデータ転送を処理できることを検証します。 非運用環境での接続とレプリケーション プロセスをテストして、この移行方法の準備を確認します。

ロールバック計画を定義する

ロールバック計画を使用すると、デプロイが失敗したりリスクが発生したりしたときに、チームは変更をすばやく元に戻すことができるようになります。 明確に定義された計画により、ダウンタイムを最小限に抑え、ビジネスへの影響を制限し、システムの信頼性を維持します。 移行またはデプロイを開始する前に、ロールバック条件と手順を常に確立してください。

1. 失敗したデプロイを定義します。 ビジネス利害関係者、ワークロード所有者、運用チームと協力して、何が失敗したデプロイと見なされるかを決定します。 たとえば、正常性チェックの失敗、パフォーマンスの低下、セキュリティの問題、未解決の成功メトリックなどがあります。 この定義により、ロールバックの決定が組織のリスク許容度と一致します。 デプロイ 計画にロールバックをトリガーする特定の条件 (CPU 使用率の制限、応答時間のしきい値、エラー率など) を含めます。 この評価により、ロールバックの決定が明確になり、インシデント中に一貫性が得られます。

2. CI/CD パイプラインのロールバック手順を自動化します。 Azure Pipelines や GitHub Actions などのツールを使用して、ロールバック プロセスを自動化します。 たとえば、正常性チェックが失敗した場合に以前のバージョンを再デプロイするようにパイプラインを構成します。

3. ワークロード固有のロールバック手順を作成します。 ワークロードの種類、環境、デプロイ方法に一致するロールバック手順を開発します。 たとえば、コードとしてのインフラストラクチャのデプロイでは、以前のテンプレートを再適用する必要があります。 アプリケーションのロールバックには、前のコンテナー イメージの再デプロイが含まれます。 ロールバック スクリプト、構成スナップショット、およびコードとしてのインフラストラクチャ テンプレートをロールバック 計画にアタッチします。 これらの資産を使用すると、迅速な実行が可能になり、手動による介入への依存を減らすことができます。

4. ロールバック プロシージャをテストします。 実稼働前環境でデプロイエラーをシミュレートし、ロールバックの有効性を検証します。 自動化、アクセス許可、または依存関係のギャップを特定して解決します。 ロールバックによってシステムが安定した既知の正常な状態に復元されることを確認します。

5. ロールバック戦略を改善する 各デプロイまたはロールバック イベントの後、振り返りを実行して、何が機能し、何がうまくいかなかったかを評価します。 学習した教訓、アーキテクチャの変更、または新しいツールに基づいて、ロールバックの条件、手順、自動化を更新します。 ロールバック戦略を最新かつ効果的な状態に保つためのドキュメントを維持します。

移行計画に関する利害関係者の関与

利害関係者の承認により、移行計画がビジネス要件とリスク許容度を満たしていることを検証します。 移行を実行する前に、正式な認可を取得する必要があります。

1. 業務上の正当な理由で移行計画を文書化します。 ワークロード名、所有者、重要度、移行方法、ダウンタイム期間、およびビジネス効果を示す構造化されたプランを作成します。 各アプローチの根拠を含め、リスクを最小限に抑える方法を説明します。

2. テスト済みのロールバック 手順を示します。 ステップ、期間、成功条件を含む特定のロールバック 計画を表示します。 自動化された機能と手動の機能を含めます。 運用前テストの結果を文書化して、迅速なサービス復元を証明します。

3. ビジネス上の制約に対してスケジュールを検証します。 重要な事業期間、メンテナンスの凍結、季節的なピークを回避するために、利害関係者とのタイムラインを確認します。 競合が存在する場合は、トレードオフのある代替オプションを指定します。

4. 正式な承認とロールバック権限を取得します。 移行計画とロールバック手順に関する利害関係者からの書面による承認をセキュリティで保護します。 意思決定機関を定義し、緊急通信チャネルを確立します。

5. 成功条件を定義し、チェックポイントを確認します。 パフォーマンス ベンチマーク、機能検証、ユーザー受け入れ基準などの測定可能なメトリックを設定します。 正式な承認/不承認決定レビューのポイントを計画します。

次のステップ