セイテクエンジニアのブログかつて山市良と呼ばれたおじさんのブログ vol.187　Azure MigrateによるVM移行－評価と計画｜Windows Server 2016 EOSまであと299日

vol.187　Azure MigrateによるVM移行－評価と計画｜Windows Server 2016 EOSまであと299日

2026年03月19日配信
執筆者：山内和朗

　Windows Server 2016の製品ライフサイクルとサポート終了日（End of Life Cycle《EOL》、End of Support《EOS》）である2027年1月12日までのカウントダウンが進んでいます。この連載シリーズのテーマの1つはAzureへの移行です。前回は2台のAzure Migrateアプライアンスを使用して、Hyper-V VMと物理サーバーの検出を開始し、検出結果を確認しました。今回は、移行前の重要なステップである、評価を実施します。なお、物理サーバー用Azure Migrateアプライアンスは、Hyper-V VMのエージェントレス移行とエージェントベースの移行（物理サーバーとして移行）の手順の違いを確認するために展開したものであり、Hyper-V VMの移行のみの場合は必要ありません。

検出されたサーバーのインベントリを確認する

　前回の最後に説明したように、Azure Migrateアプライアンスで検出された情報のメタデータは、Azure Migrateのプロジェクトへ送信され、格納されます。AzureポータルでAzure Migrateプロジェクトの「イベントリを探す > すべてインベントリ」を開くと、検出されたインベントリとしてサーバー（VM）の一覧と、ゲスト検出を有効にした場合はゲスト検出で検出されたWebアプリやデータベースとの関連付けを確認できます（画面1）。　「ソフトウェア」「Webアプリ」「データベース」では、ゲスト検出で収集された情報を確認できます。今回の移行では行いませんが、「Webアプリ」や「データベース」は、最新化（モダン化）、つまり、PaaSへの移行に必要なインベントリになります。

画面1　Azure Migrateアプライアンスの検出結果をAzureポータルで確認する。vm01、vm02、vm03はHyper-V用アプライアンスで検出されたサーバー（Hyper-V VM）。dc01は物理用アプライアンスで検出されたサーバー（物理マシン、実体はHyper-V VM）

画面1　Azure Migrateアプライアンスの検出結果をAzureポータルで確認する。vm01、vm02、vm03はHyper-V用アプライアンスで検出されたサーバー（Hyper-V VM）。dc01は物理用アプライアンスで検出されたサーバー（物理マシン、ただしその実体はHyper-V VM）

　「分析情報（プレビュー）」では脆弱性やソフトウェアのライフサイクル、保留中（インストールされるべき）の更新プログラムなど、サーバー（VM）の現在のセキュリティリスクを評価することができるので、次のステップ（評価と計画）に進む前に事前に対処できます（画面2）。ゲスト検出に問題がある場合は、「アクションセンター」に報告されるので、必要な修正（資格情報の見直しなど）を行ってください（画面3）。

画面2　「分析情報（プレビュー）」では、サーバー（VM）の保留中の更新プログラムの有無や、セキュリティリスクを確認できる

画面3　「アクションセンター」の通知。ゲスト検出のエラー解消のために、資格情報の訂正や、委任設定（Enable-WSManCredSSP）、ポートの許可などが必要な場合も

評価を作成する

　検出されたサーバーの一覧から、Hyper-V VMの一台「vm03」を移行対象の候補とします。移行のステップに進む前に、Azure VMに移行できるかどうかの対応性や、移行後のコストを見積もるため、次のステップである「評価」を作成します。なお、vm01とvm02はAzure Migrateアプライアンスを使用しない方法で移行を実施済みです（その後、Azureから削除）。今回は1台だけの評価を作成しますが、オンプレミスで検出された多数のサーバーを一括で評価できるということを指摘しておきます。

　AzureポータルでAzure Migrateプロジェクトの「アクションセンター｜インベントリを探す｜すべてのインベントリ」を開き、検出されたサーバーの一覧から「vm03」を選択して、「＋評価の作成」をクリックします（画面4）。「評価の作成」の「基本情報」で評価名を入力し、「全般」タブでターゲットの場所（移行先のリージョン）や既定の環境（実稼働またはDev/Test）、Azureプラン（従量課金制など）、通貨単位、サイズ設定の基準、稼働率、Azureハイブリッド特典の利用可否などの評価要件を指定して、評価を作成し、評価の作成が完了するまで待ちます（画面5）。Azure Migrateアプライアンスを使用する場合、使用しない場合（vol.178を参照）とは異なり、サイズ設定の基準として、1日、1週間、または1か月のパフォーマンス履歴に基づいて、Azureに適したサイズをターゲット設定させることができます。また、ゲスト検出を利用している場合、サーバーの移行だけでなく、アプリやデータベースの最新化（モダン化）の対応性の評価も同時に行え、移行方法を比較検討できます（「詳細」タブの設定は既定のままで構いません）。

画面4　検出されたサーバーの一覧から、移行候補を1台以上を選択し、移行先やサイズ設定基準などを調整し、評価を作成する
画面4　検出されたサーバーの一覧から、移行候補を1台以上選択し、移行先やサイズ設定基準などを調整し、評価を作成する

画面5　評価の作成が完了すると、「決定と計画 > 評価」に評価レポートが利用可能になる

評価レポートを確認する

　作成された評価レポートを開き、その内容を確認します。ゲスト検出が利用可能であった場合、サーバーの移行（Azure VMへのリフトアンドシフト）だけでなく、アプリやデータベースのPaaS移行についての評価も作成されます。「移行の基本設定」で「最新化（モダン化）」と「移行時間の最小化」のいずれかを選択すると、推奨の移行パスが示されます（画面6）。今回は、サーバー移行が目的なので、「Azure VMへ（リフトアンドシフト）」の評価レポートを確認します。

　評価には、Azureへの移行の準備状況（対応、条件付き対応など）、移行先（ターゲット）VMのサイズの推奨、移行後のコストの見積もり、移行のためのガイダンス（移行に関する問題など）が含まれます（画面7）。Azureへの移行が「対応」または「条件付き対応」であれば、通常、問題なく移行できます。例えば、サーバーのデータディスクがAzureの上限（64TB）を超える場合、そのままではAzureに移行することはできないため、「未対応（日本語訳は対応未確認となっていますが、Not readyのこと）」と評価されます。

　サイズの基準を「パフォーマンスベース」にした場合は、収集されたパフォーマンスデータに基づいてサイズ（VMのサイズやマネージドディスクのサイズ）の推奨設定が示されます。「オンプレミス」にした場合は、パフォーマンスに関係なく、オンプレミスの現在の割り当てサイズに基づいてサイズの推奨事項が示されます。

画面6　ゲスト検出が利用可能であったため、サーバー移行だけでなく、PaaS移行の評価も行われた

画面7　サーバー移行のための「Azure VMへ（リフトアンドシフト）」の評価レポートで、Azureへの対応性や、推奨サイズを確認する（サイズは移行時、移行後に変更可能）

ウェーブ計画を作成する（大規模移行向け、省略可能）

　AzureポータルのAzure Migrateプロジェクトにおいて、評価の次のステップは「ウェーブの作成」のように見えます。このウェーブ（計画）の作成は必須ではありません。ウェーブ計画は、大規模な移行プロジェクトで、依存関係などの要件を保ちながら、計画した時間に合わせて段階的に移行を進めていく計画を作成し、移行の各段階の進捗を自動または手動で追跡する機能を提供します（画面8、画面9）。なお、この機能は現在、プレビュー段階です。今回のように1台（または少数）のVMの移行では、ウェーブを作成する利点は全くありません。また、ウェーブ計画は移行プロセスを自動または手動で追跡するもので、移行作業自体を自動化するものでもないようです。

画面8　ウェーブ計画の作成。いつまでにすべての移行を完了するか計画を策定する