移行を準備する

  • 10 分

個々のワークロードの移行を計画する前に、組織とクラウド リソースで移行をサポートする準備をしておく必要があります。

移行手法の手順を示す図。

Azure ランディング ゾーンのどの参照実装を使うかに関係なく、移行プロジェクトが成功するようにランディング ゾーンを準備するには、いくつかのタスクを実行する必要があります。

  • ハイブリッド接続を確立します。 Azure ランディング ゾーンのデプロイの間に、ハブ仮想ネットワークとネットワーク ゲートウェイを含む接続サブスクリプションをデプロイできます。 Azure ランディング ゾーンをデプロイした後、これらのゲートウェイからハイブリッド接続を構成して、既存のデータセンター アプライアンスまたは ExpressRoute 回線に接続します。

  • ID を準備します。 Azure ランディング ゾーンのデプロイの間に、ID プラットフォームのサポート アーキテクチャもデプロイする必要があります。 Azure ランディング ゾーンをデプロイした後、ID リソースをデプロイする必要があります。

  • Active Directory ドメイン コントローラーを拡張します。 レプリケーション トポロジをサポートするには、デプロイした ID ネットワーク領域内で Azure に追加のドメイン コントローラーをデプロイすることが必要な場合があります。

  • ハイブリッド DNS を有効にします。 既存の環境の一部である名前空間に対するドメイン ネーム システム (DNS) 要求を解決でき、既存の環境内のリソースが Azure 内のリソースを確実に解決できるように、DNS サービス を構成します。

  • カスタム DNS 解決。 ドメイン ネーム システム リゾルバーに Active Directory を使う場合、またはパートナー ソリューションをデプロイする場合は、VM をデプロイする必要があります。 ドメイン コントローラーを ID サブスクリプションとネットワーク スポークにデプロイする場合は、これらの VM を DNS サーバー として使うことができます。 それ以外の場合は、これらのサービスを収容するように VM をデプロイおよび構成する必要があります。

    VM をデプロイした後、既存の名前空間に対して検索を実行できるように、VM を既存の DNS プラットフォームに統合する必要があります。

  • Azure Firewall DNS プロキシを構成します。 トラフィックを受信して Azure リゾルバーまたは DNS サーバーに転送するように、Azure Firewall を DNS プロキシとして構成することができます。 この構成を使って、オンプレミスから Azure への参照を実行します。

  • ハブのファイアウォールを構成します。 ユーザーが明示的な許可規則を追加するまで、Azure ファイアウォールはトラフィックをブロックします。 すべての有効なワークロードに標準規則を適用し、ワークロードのニーズに基づいて個別に規則と規則コレクションを適用します。

  • ルーティングを確立します。 Azure で提供されているリソース間のルーティングを使うと、追加の構成を実装する必要はありません。 または、追加の構成を必要とする他のルーティング シナリオを使うこともできます。

    不明な場所へのトラフィックがファイアウォールに送信されるように、スポーク間ルーティングを構成します。これによってトラフィックが検査され、ファイアウォール規則が適用されます。 ハブに仮想ネットワークを使う場合は、ゲートウェイから送られてくるトラフィックの検査を処理する方法も計画する必要があります。

  • サブスクリプション サービスを有効にします。 新しいサブスクリプションを作成するプロセスを自動化して高速化します。

  • Microsoft Defender for Cloud を有効にするポリシーを設定します。 ランディング ゾーンをデプロイするときは、Azure サブスクリプションに対して Defender for Cloud を有効にするポリシーを設定する必要があります。 Defender for Cloud はセキュア スコアを通じてセキュリティ態勢に関する推奨事項を提供します。これは Microsoft Security ベースラインに基づいてデプロイされたリソースを評価します。

ツールと初期移行バックログの準備

移行を正常に完了するには、修復アクティビティを含め、繰り返しを通じてワークロードを評価、レプリケート、追跡するためのツールが必要です。

検出、評価、レプリケーションのタスクを実行するには、Azure Migrate を使用できます。 プロジェクトのアクティビティを整理するには、Azure DevOps、Excel、Microsoft Project を使用できます。 移行実行ガイドを使って、移行プロセスに関するガイダンスを得ることもできます。

次のものを含むバックログを作成する必要もあります。

  • ビジネスの結果とメトリック。
  • ビジネスの優先順位。
  • コアとなる前提条件。

すべてのチームにバックログについて熟知させ、それを共有の場所に格納します。 移行プロセス全体を通して使用できるようにバックログを維持します。 プロジェクト管理ツールでエピックを作成し、複数のデータセンターの作業を追跡することもできます。

Azure Migrate

Azure Migrate は、統合された移行プラットフォームを提供します。これは、Azure への移行を開始、実行、追跡するための単一のポータルです。 Azure Migrate ハブでは、以下の評価と移行を行うことができます。

  • サーバー、データベース、Web アプリ: Web アプリや SQL Server インスタンスなどのオンプレミス サーバーを評価して、Azure にそれらを移行します。

  • データベース: オンプレミスの SQL Server インスタンスとデータベースを評価し、Azure 仮想マシン上の SQL Server、Azure SQL Managed Instance、または Azure SQL Database にそれらを移行します。

  • Web アプリケーション:オンプレミスの Web アプリケーションを評価し、Azure App Service と Azure Kubernetes Service (AKS) にそれらを移行します。

  • 仮想デスクトップ: オンプレミスの仮想デスクトップ インフラストラクチャ (VDI) を評価し、Azure Virtual Desktop に移行します。

  • データ:Azure Data Box 製品を使って、大量のデータをすばやく経済的に Azure に移行します。

役割と責任を一致させる

クラウド導入フレームワークは、移行における組織の連携の役割を明らかにして、主要な機能を果たすための部門間のコラボレーションを推進します。

次の表は、クラウド戦略職務の役割とその責任について説明したものです。

ロール 責任
プロジェクト スポンサー 移行のスコープを定義して、移動するリソースと各リソースを移動する利点を決定します。 移行ツールの購入、全体的なワークロード アーキテクチャ、およびリリース アクティビティの意思決定所有権を提供します。
プロジェクト マネージャー 移行スコープのプロジェクト計画を推進します。 テスト プロセスを駆動します。 関係者に対する状態の更新を整理します。
組織の変更マネージャー プロジェクト チームが変更を組織に伝えるのに役立ちます。 さまざまな機能を使用して、適切なチーム メンバーが関与し、移行をサポートするために正しい組織の変更が行われることを確認します。
ライセンス スペシャリスト プロジェクトが適切にライセンスされ、既存のライセンスリソースを使用していることを確認するためのライセンス分析情報と財務運用管理を提供します。
ワークロード経営者 ワークロードの評価、アーキテクチャ、および移行プロセスの意思決定所有権を提供します。 Azure のワークロードのビジネス価値の所有者として機能します。

Azure への移行中は、クラウド導入職務の次の役割が、ほとんどの技術的なタスクを実行します。

ロール 責任
移行アーキテクト 移行ウェーブ計画やすべての移行プロセスなど、ワークロードの技術的な意思決定を監督します。
移行エンジニア プロジェクトの一部として識別されるタスクを実行します。

次の表は、他の職務に必要になる可能性があるサポート的役割について説明したものです。

ロール 責任
ランディング ゾーン アーキテクト ワークロードをランディング ゾーンに移行するためのサポートを提供します。 ランディング ゾーンのプラットフォーム サービスに関する問題を修復するのに役立ちます。 詳細については、「クラウド プラットフォーム機能」を参照してください。
Cloud Operations Manager ワークロードを移行するときに適切な管理が行われるように、管理プラットフォームへのワークロードの移行をオンボードするためのサポートを提供します。 詳細については、「クラウド 操作機能」を参照してください。
ワークロード アーキテクト 移行ワークロードの設計に関するアーキテクチャ ガイダンスと意思決定を提供します。 ワークロードごとに、このロールの複数のインスタンスを満たすために、特定の主題の専門家が必要になる場合があります。 詳細については、「中央 IT 機能」を参照してください。
ユーザー受け入れテスター 個々のワークロードのテスト ユーザー受け入れテスト (UAT) のフィードバックを提供するために、ワークロードごとにこのロールのインスタンスが複数ある場合があります。 詳細については、「中央 IT 機能」を参照してください。

移行するワークロードのサイズと数によっては、各役割に複数のチーム メンバーを割り当てる必要がある場合があります。 スケールアウトを行う必要がある場合は、プログラム マネージャーまたは移行アーキテクチャ リーダーについても計画する必要があります。 責任マトリックスを使って、役割を明確にして整理します。