マイグレート
移行手法 を使用して、クラウドへの移行の準備と実行を行うことができます。 移行手法には、4 つの段階があります。
このアプローチはベンダーに依存しないため、ワークロードを任意のクラウド サービスに移行できます。
移行の準備
個々のワークロードの移行を計画する前に、移行をサポートするために組織とクラウド リソースを 準備 必要があります。 使用する Azure ランディング ゾーン参照の実装に関係なく、移行プロジェクトを成功させるためにランディング ゾーン を準備、次のタスクを実行することが必要になる場合があります。
- ハイブリッド接続を確立します。
- ID を準備します。
- Active Directory ドメイン コントローラーを拡張します。
- ハイブリッド ドメイン ネーム システム (DNS) を有効にします。
- カスタム DNS 解決を構成します。
- Azure Firewall DNS プロキシを構成します。
- ハブ ファイアウォールを構成します。
- ルーティングを確立します。
- サブスクリプションの自動販売機を有効にします。
- Microsoft Defender for Cloud を有効にするポリシーを設定します。
また、修復アクティビティを含むイテレーションを通じてワークロードを評価、レプリケート、追跡するためのツール を準備 必要があります。 次のようなリソースを使用できます。
- Azure Migrate と Modernize
- Azure DevOps の
- Microsoft Project を する
- 移行実行ガイドの を する
また、移行プロセス全体で使用できるバックログも保持する必要があります。 バックログは、潜在的なリスクを特定し、すべてのチームに進行状況を通知するのに役立ちます。 次のような情報を含めます。
- ビジネスの成果とメトリック。
- ビジネスの優先順位。
- 主要な前提条件。
計画と実装からコミュニケーションとサポートまで、移行のすべての側面をカバーするロールを適切に割り当てる必要があります。 各ロールには、移行プロジェクトの全体的な成功に貢献する特定の責任があります。
ワークロードを評価する
準備を確立したら、ワークロード の準備状況を評価し、移行された状態を計画します。 クラウド導入チームは、技術的な互換性、必要なアーキテクチャ、パフォーマンスとサイズの期待、依存関係を評価する必要があります。 Azure での運用コストを計算します。
停止がビジネスに及ぼす影響に基づいてワークロード を分類します。 また、そのデータの潜在的なリークがビジネスや顧客にどのように影響するかに基づいて、ワークロード内のデータを分類します。 機密性の高いデータは、セキュリティ リスクを高めます。
すべての資産と関連する依存関係がデプロイ モデルとクラウド プロバイダーと互換性があることを確認します。 移行の阻害要因があるかどうかを評価し、互換性の問題の必要な修復を文書化します。
ワークロードの移行対象の状態を設計します。 このプロセス中に、次の側面を設計します。
- アプリケーション ランディング ゾーンのアーキテクチャ
- リソースを使用したワークロード ネットワーク アーキテクチャ
- ワークロードの依存関係
- コンフィデンシャル コンピューティング
重要なコンポーネントを設計したら、クラウドの見積もりを見直し、必要に応じて調整を行います。
資産をデプロイする
すべてのサービス をデプロイして、ワークロードがクラウドで正常に動作できることを確認します。 ワークロードには、リソースの編成、ネットワーク、ID とセキュリティ、および管理のためのサービスが必要な場合があります。 資産がクラウド プロバイダーと互換性がない可能性がある構成を特定します。 必要な修復を実行して、ワークロードをクラウドで適切にレプリケートしてステージングできるようにします。
レプリケーション プロセス は、次の手順で構成されます。
- レプリケート: さまざまなバイナリのポイントインタイム バージョンをコピーします。
- シード: バイナリ スナップショットを新しいプラットフォームにコピーし、新しいハードウェアにデプロイします。
- 同期: 新しいバイナリと古いバイナリを配置します。
移行が完了したら、障害、侵害、パフォーマンス低下などの問題を防ぐために管理アクティビティを実行する準備をします。 アーキテクチャと管理計画をテストします。 移行テストでは、IT アクティビティに重点を置いています。 テスト中に検出した問題を一覧表示して、それらを追跡して修復できるようにします。 運用環境のワークロードに影響を与えないように、分離された環境でテスト移行を実行します。 ライブ システムと並列に実行されるソース システムのレプリカを作成できます。
ワークロードを解放する
ワークロード を解放するには、次の作業を行う必要があります。
- 今後の変更を他のチームに伝えます。
- 移行手順を完了します。
- 最終的な変更の承認を行います。
- リソースをクリーンアップします。
- 振り返りを行います。
今後の変更について組織に通知して、移行が影響を受ける可能性があることをすべてのユーザーに確実に把握させます。 各ワークロードには専用のユーザーとオペレーターが含まれているため、各ワークロードの変更を伝えます。
ワークロードのビジネス ユーザーは、新しいソリューション をテスト必要があります。 変更が最も影響を受ける可能性があるユーザーを特定します。 これらのユーザーに、ビジネス目標、望ましい成果、ビジネス プロセスに対する予想される変更を通知します。 フィードバックを収集し、結果の技術的なアクションを管理します。
資産とそのすべての依存関係を運用環境に昇格したら、運用トラフィックを再ルーティングできます。 その後、オンプレミスの資産は古くなっており、使用を停止できます。 移行後、ライブ データに基づいてワークロードを最適化し、廃止された資産の使用を停止します。
移行後に の振り返り を行って、何がうまくいったか、何が改善されたのか、学んだことを確認します。 チームの各メンバーから分析情報を得て、学習した教訓を将来の移行に適用できるようにします。