Azure Migrate入門｜オンプレサーバーをAzureへ移行する評価・依存関係マッピング・コスト試算の実践ガイド

オンプレのサーバーをAzureへ移行したいけど、何から手をつければいいかわからない——そんな状況で相談を受けることがよくあります。

「とりあえずVMをそのままリフト＆シフトすればいい」と思っていると、移行後に「月額コストが想定の倍になった」「依存するDBサーバーを移行し忘れた」「移行後にアプリが動かなくなった」という問題が続出します。現場の実態を把握していない計画書どおりに動いて失敗する、典型的なパターンです。

Azure Migrateは、こうした問題を未然に防ぐためのAzure公式の移行支援サービスです。移行前に現環境を自動で棚卸しし、サーバー間の依存関係を可視化し、移行後の月額コストを試算できます。

この記事では、Azure Migrateの全体像とコンポーネントの理解から、アプライアンスのセットアップ、依存関係マッピング、アセスメントとコスト試算、実際の移行実行まで、インフラエンジニアが現場で使えるレベルで解説します。

なぜ「見えない移行計画」が失敗するのか

オンプレ環境を長年運用していると、「どのサーバーが何に依存しているか」が誰にも正確に把握されていない状態になりがちです。vCenterで個々のVMは監視できても、「このWebサーバーが依存しているバックエンドAPIサーバーはどれか」「このDBに接続しているアプリは何台あるか」という横断的な依存関係図は、多くの現場で存在しません。

Azureへの移行計画を立てるとき、この「依存関係の不透明さ」が最大のリスクになります。依存関係を把握しないまま移行すると、Aだけ移行してBがオンプレに残り、その間の通信が切れる——という事故が実際に起きています。

もう一つの落とし穴がコスト試算です。「オンプレで8コア・32GBのVMが動いているから、同スペックのAzure VMにすればいい」と考えると、実際のCPU使用率が5%しかなかった場合に過剰スペックのVMを選んで月額コストが膨らみます。Azure Migrateはこれら2つの課題——依存関係の可視化と性能ベースのコスト試算——を自動化します。

Azure Migrateとは？コンポーネントの全体像

Azure Migrateは、Azureポータル上のHub（一元管理ダッシュボード）として提供される移行支援サービスです。オンプレ環境にアプライアンス（軽量VM）を1台置くだけで、対象サーバーの自動検出から移行後コストの試算、実際の移行実行まで一気通貫で行えます。

① Discovery and Assessment（検出とアセスメント）

アプライアンス経由でオンプレサーバーを自動検出し、サーバーの仕様・ソフトウェア・パフォーマンスデータを収集します。収集したデータをもとに、Azure VMへの移行可否（準備状況）と推奨サイズ、月額コスト試算を提示します。

② Server Migration（サーバー移行）

Discovery and Assessmentで計画が固まったあと、実際の移行（レプリケーション→テスト移行→カットオーバー）を実行するツールです。バックエンドにはAzure Site Recovery（ASR）が使われており、VMwareへのエージェントレスレプリケーションにも対応しています。

③ Azure Database Migration Service

SQL ServerをはじめとするオンプレDBをAzure SQL DatabaseやAzure Database for MySQL/PostgreSQLへ移行するためのサービスです。事前互換性チェックと実際のデータ移行を担います。本記事はサーバー移行（VM）を中心に扱います。

ステップ1 — アプライアンスのセットアップ

Azure Migrateの最初のステップは、オンプレ環境にAzure Migrate アプライアンスをデプロイすることです。このアプライアンスは軽量な管理VMで、検出・データ収集・レプリケーションのゲートウェイとして機能します。

1. アプライアンスファイルのダウンロードとデプロイ

Azureポータルで「Azure Migrate」→「サーバー、データベース、Webアプリ」→「検出と評価」からプロジェクトを作成します。プラットフォームによってダウンロードするファイルが異なります。

・VMware環境: OVAテンプレート（ESXi 6.5以上、vCenter必須）
・Hyper-V環境: VHDファイル（Windows Server 2012 R2以上のHyper-Vホスト）
・物理サーバー・その他: PowerShellインストーラースクリプト（Windows Server 2016以上）

アプライアンスVMのスペック要件は、CPUコア数8・メモリ16GB・ストレージ80GBです。検出対象が1,000台規模の環境でも同じスペックで対応できます。

2. Azureへの登録

アプライアンスを起動すると、Webベースの構成ウィザードが起動します。ここでAzureポータルで発行したプロジェクトキーを入力してAzure Migrateプロジェクトに接続します。VMware環境の場合は、接続するvCenterのアドレスと読み取り専用の認証情報も入力します。

登録後、アプライアンスは定期的にAzure Migrateサービスへメタデータを送信し始めます。

ステップ2 — オンプレサーバーの自動検出

アプライアンスが稼働を始めると、vCenter（VMware）またはHyper-VホストのAPIにアクセスし、管理下にある全VMを自動検出します。物理サーバーの場合は、WMI/SSHでのエージェントレス検出またはCSVインポートが使えます。

検出される情報は以下のとおりです。

・基本情報: ホスト名・IPアドレス・OS・CPU/メモリの割り当て量
・ディスク情報: ディスク数・サイズ・使用量
・ネットワーク情報: NIC数・MACアドレス・IPアドレス
・インストール済みソフトウェア: アプリケーション一覧（Windows: レジストリ参照、Linux: dpkg/rpm参照）

パフォーマンスデータ収集

初期検出でVM一覧が取れたら、次はパフォーマンスデータの収集期間を設けます。検出開始から1日経過すればアセスメントを実行できますが、実際の負荷パターンを反映するには30日以上の収集を推奨します。

収集されるパフォーマンスデータは、CPU・メモリ使用率（ピーク・平均・95パーセンタイル）、ディスクスループット、ネットワーク送受信量です。このデータが後のサイジング精度に直結します。

ステップ3 — 依存関係マッピング

依存関係マッピングは、サーバー間のネットワーク通信（どのサーバーがどのサーバーとやり取りしているか）を可視化する機能です。移行グループ（同時に移行すべきVMのセット）を決定するために使います。

VMware環境であればエージェントレスが使えるため、エージェントの展開コストなしに依存関係を可視化できます。Hyper-Vや物理サーバーはエージェントベースが必要ですが、より詳細な情報が得られます。

依存関係マップで確認すべきポイントは2つです。

・移行グループの確定: 互いに通信しているサーバー群は同じグループで同時に移行する必要があります。依存グループをまたいで移行すると通信断が起きます。
・想定外の接続先の発見: 長年運用している環境では、ドキュメントに記載のない内部通信が存在することがあります。移行前に必ず確認します。

移行の段階的な進め方については、AWSでもAzureでも考え方は共通しています。移行戦略の全体像はAWS移行の6R入門が参考になります。

ステップ4 — アセスメントとコスト試算

検出とパフォーマンスデータ収集が終わったら、アセスメントを実行します。「このVMをAzureへ移行した場合、どのVMサイズが適切か」「準備が整っているか」「月額いくらかかるか」をレポートとして出力します。

サーバー準備状況チェック

アセスメントの結果で各VMに以下のステータスが付きます。

・準備完了（Ready）: そのままAzure VMに移行できる状態です。
・条件付き準備完了（Conditionally Ready）: 一部対応が必要（例: BIOSブートのVMでGeneration 2への変換が推奨される）。
・準備未完了（Not Ready）: 直接移行不可。OSが非サポート（Windows Server 2003など）の場合に出ます。
・準備不明（Readiness Unknown）: パフォーマンスデータが不足しているため判定不能。収集期間を延ばして再実行します。

パフォーマンスベース vs オンプレ踏襲サイジング

Azure Migrateのサイジング方式には2種類あります。

・パフォーマンスベース（推奨）: 収集した実際のCPU/メモリ使用率からAzure VMのサイズを推奨します。8コア・32GBのVMでも使用率が5%なら、それに見合った小さいサイズを提案してくれます。
・オンプレ踏襲（As-on-premises）: 割り当て済みスペックをそのままAzure VMに対応させます。移行後の検証や急ぎの移行に使います。

パフォーマンスベースのサイジングで95パーセンタイル値を採用するのが基本です。ピーク（100パーセンタイル）を使うと過剰スペックになりやすく、平均（50パーセンタイル）では負荷スパイク時に不足します。

Azure Hybrid BenefitとReserved Instancesの反映

コスト試算では以下の割引をアセスメント設定に反映できます。

・Azure Hybrid Benefit: Software Assurance付きのWindows Serverライセンスを持っている場合、Azure VMのOS料金が最大40%割引になります。アセスメント時にオンにして試算すると現実的な費用が出ます。
・Reserved VM Instances（1年・3年）: 1年リザーブドで約37%、3年で最大60%の割引を反映できます。アセスメントの「割引オプション」から設定します。

クラウド移行後のコスト構造の変化（CapEx→OpEx）については、CapExとOpExの違いで詳しく解説しています。TCO試算の全体的な考え方を整理するのに役立ちます。

ステップ5 — 実際の移行（Server Migration）

アセスメントで移行計画が確定したら、Server Migrationツールで実際の移行を実行します。移行の流れは「レプリケーション→テスト移行→本番カットオーバー」の3段階です。

VMwareエージェントレスレプリケーション

VMware環境では、Mobility Serviceエージェントを各VMにインストールせず、アプライアンス経由でVMのディスクデータをAzureへレプリケーションできます。操作の流れは次のとおりです。

# Azure Migrate → Server Migration の操作フロー（概念）
# 1. VMware VMsの検出（Discovery and Assessmentで実施済み）
# 2. 移行対象VMを選択し「レプリケーション」を開始
# 3. ターゲット設定: リージョン / リソースグループ / VNet / サブネット / VMサイズ
# 4. 初期レプリケーション（シードコピー）: ディスク全体をAzureへコピー
#    ※数GB～数TBのVMでは数時間～数日かかる場合がある
# 5. 差分同期: シードコピー完了後は変更分のみを定期同期
# 6. テスト移行: 本番VMを稼働させたままAzure上にテストVMを起動
# 7. テスト確認後: テストVMをクリーンアップ
# 8. 本番カットオーバー: 最終差分同期 → 元VMシャットダウン → Azure VMを起動

テスト移行（ダウンタイムゼロで事前確認）

テスト移行は、元のオンプレVMを稼働させたまま、Azure上に移行先VMのコピーを起動できる機能です。テスト用サブネットに接続するため、本番通信には影響しません。

テスト移行で必ず確認すべき項目は以下のとおりです。

・アプリケーションの起動確認（OSブートのみでなく、実際のサービス起動まで確認）
・ネットワーク疎通（接続先DBやAPIサーバーへの通信が通るか）
・パフォーマンス（選択したAzure VMサイズで実負荷に対応できるか）
・Windowsライセンス認証（Azure自動ライセンス認証が正常に動作するか）

カットオーバー

テスト移行が問題なければ、カットオーバー（本番移行）を実行します。カットオーバー前に最終差分同期が行われ、その後オンプレのVMをシャットダウンしてAzure VMを起動します。DNSやロードバランサーの向き先を変更して移行完了です。

カットオーバー後は元のオンプレVMを一定期間（最低2週間程度）保持し、問題がないことを確認してから削除するのが安全です。

料金の仕組み（2026年10月時点）

Azure Migrate自体の主要機能は無料ですが、以下の付随コストが発生します。

実際の大部分のコストは、移行後に稼働するAzure VMの月額費用です。アセスメントのコスト試算結果を参考に、移行前にしっかり予算計画を立てておきましょう。

よくあるトラブルと対処法

アプライアンスがAzureへ登録できない

アプライアンスからAzureへの通信には、複数のFQDN（*.backup.windowsazure.com、*.blob.core.windows.netなど）へのHTTPS（443番ポート）が必要です。オンプレのProxyやファイアウォールでブロックされているケースが最も多いです。アプライアンス構成ウィザードにはProxy設定欄があるので、環境に合わせて設定します。

検出されないVMがある

vCenterの認証情報に読み取り権限が正しく設定されているか確認します。また、vCenterとESXiホストへのTCP 443とTCP 902（ESXiエージェント用）が開いているかもチェックします。ネストした仮想化やvAppは検出されないことがある点にも注意が必要です。

アセスメントが「準備未完了」ばかり出る

最も多い原因は古いOSです。Windows Server 2008 R2以前、RHEL 5以前など、Azureのサポート外OSは「Not Ready」と判定されます。このようなVMは移行前にOSアップグレードを行うか、移行対象外とするかを意思決定する必要があります。

初期レプリケーションが遅い

初期レプリケーション（シードコピー）はディスク全体のデータ転送が必要です。数TB以上のVMでは数日かかることがあります。アプライアンスVMのネットワーク帯域と、インターネット回線のアップリンク速度がボトルネックになります。大規模移行ではAzure ExpressRouteの利用を検討します。

まとめ — Azure Migrateで「見える移行計画」を立てる

Azure Migrateは、オンプレからAzureへの移行を「勘と気合い」ではなく、データに基づいて計画・実行するためのツールです。アプライアンス1台をデプロイするだけで、数百台のサーバーを一括検出し、依存関係を可視化し、コストを試算できます。

移行プロジェクトの現場では「把握していなかった依存関係」と「甘いコスト試算」が最大の失敗原因です。Azure Migrateをプロジェクト初期に導入し、移行対象を正確に把握した上で計画を立てることが、スムーズなAzure移行への第一歩です。