Azure VPN Gateway の Basic Public IP を Standard SKU に「アップグレード（移行）」しようとして Prepare が失敗し、CannotContinueMigrateGatewayWithIncorrectState など抽象的なエラーで止まってしまう――そんな現場の“あるある”を、2025〜2026 年の最新ロードマップと付き合わせて、最短・低リスクで解決するための実務ガイドとして整理しました。自動移行・手動移行の境界、実際に効く対処、ダウンタイムの見積もりまで一気に把握できます。
目次
問題の整理：なぜ「Prepare」が失敗するのか
今回の前提は次のとおりです。
- 対象リソース：Virtual Network Gateway（Gateway SKU: Standard、Gateway Type: VPN、VPN Type: Route‑based、Public IP SKU: Basic）
- 実施内容：Azure Portal または PowerShell から「Basic Public IP → Standard SKU」への移行ウィザード（Migrate タブ）を実行
- 現象：検証は通るが
Prepareが失敗。代表例としてCannotContinueMigrateGatewayWithIncorrectState（現状態がAbortなのでPrepareできない）などが出る - 補足：GatewaySubnet を /27 へ拡張済み
この失敗の多くは、以下の事情が重なって発生します。
- ロードマップの段階的適用：Basic→Standard IP への移行機能・サポート対象は段階的にロールアウトされ、SKU（レガシー / 新世代）・冗長構成（AZ / 非 AZ、Active-Active 対応）・リージョンによって可否や振る舞いが異なる期間がありました。
- ゲートウェイ移行と IP 移行が別物：「ゲートウェイ SKU の整理（レガシー Standard / HighPerformance → VpnGw1AZ/2AZ など）」と「Public IP の Basic → Standard 化」は別トラックで進みます。前者は最終的に自動実施、後者はポータルからの顧客主導移行が基本です。
- 移行ステートの不整合：過去の中断や一部失敗で、
Abortなどの内部ステートが残留するとPrepareを弾かれることがあります。ユーザー操作だけでは復旧できないケースがあり、サポートでステートのリセットが必要になる場合があります。
結論（最短の対処方針）
レガシー Gateway SKU（Standard／High Performance）× Basic Public IP の組み合わせで「Prepare」が失敗する場合、2025 年 11 月時点では次の判断が最も安全かつ実務的です。
- ゲートウェイ本体：レガシー SKU は最終的に 自動的に AZ 対応 SKU（例：Standard → VpnGw1AZ）へ移行されます。自分で SKU を作り直す必要はありません。
- Public IP：VPN Gateway に紐付く Basic Public IP は顧客主導で Standard へ移行します（ポータルの Migrate タブ、または PowerShell）。移行中 5〜10 分程度の停止が見込まれるため、業務時間外の計画作業にします。
- 「Prepare」失敗時：チェックリスト（後述）を満たしても解消しない場合は、Azure サポートにチケットを発行し、Migration ステートのリセットや裏側の回復を依頼します。
タイムラインの正しい読み方（2025〜2026 年）
混乱の元になりやすいポイントを、2025/11 時点の整理として時系列でまとめます。なお、予告なく変更されることがあります。
| 時期 | 対象／イベント | ユーザーの推奨対応 | 備考 |
|---|---|---|---|
| 2025 年 8 月〜 | VPN Gateway の Basic → Standard IP 移行ツール（ポータル）が順次提供 | 対象ゲートウェイで Migrate タブが見えたら検証 | アクティブ／パッシブ構成から先行。リージョンにより段階提供 |
| 2025 年 9 月 30 日 | プラットフォーム全体としての Basic Public IP 廃止日 | VPN Gateway 以外は期限厳守で Standard 化 | VPN Gateway については後述の延長適用あり |
| 2025 年 11 月頃 | レガシー Gateway SKU（Standard／HighPerformance）向けの顧客主導移行エクスペリエンスが概ね利用可能に | レガシー SKU + Basic IP の環境でポータル移行の再試行 | 表示されない場合はロールアウト待ち or 条件未充足 |
| 〜2026 年 3 月末 | VPN Gateway における Basic Public IP の実質的な対応期限 | 計画停止を確保し、ポータル（または PowerShell）で Standard へ移行 | ツール移行は 5〜10 分程度の停止。IP アドレスは維持される |
| 2026 年 3 月末 | レガシー Gateway SKU の最終リタイアフェーズ | 未対応の残存環境はバックエンドで自動移行 | 計画外の瞬断が発生し得るため、前倒し実施が無難 |
要点：「ゲートウェイ本体の SKU 移行」は最終的に Microsoft 側で面倒を見てくれます。一方「Basic Public IP の Standard 化」は、できるだけ自分たちで計画移行しておくのが安全です（ツール利用時は IP 不変）。
Basic Public IP → Standard SKU 移行の仕様と前提
- IP アドレスは変わらない：ポータル／PowerShell の移行機能を使う場合、同じグローバル IP のまま Basic → Standard へ変換されます。
- ダウンタイムは 5〜10 分目安：
Executeステップの間は切断されます。全体のエンドツーエンドは 2 時間程度かかることもありますが、多くは 1 時間以内で完了します。 - GatewaySubnet の空き IP が必須：現行プレフィックス内に 最低 3 アドレスの空きが必要です。/28 以下は失敗しやすく、/27 以上推奨。必要に応じて 複数プレフィックスの追加で空きを確保します。
- 提供状況は段階的：Migrate タブが表示されない／押下できない場合は、リージョン／SKU／構成の組合せが未サポートか、前提未充足（後述チェックリスト）です。
- アクティブ／アクティブ構成：ツールの対応は時期により差があり、構成次第で一時的に利用できない期間がありました。該当時は一旦待機か、代替手段（再作成）を検討します。
最短・低リスクの運用方針（サマリ）
| 状況 | 推奨アクション | ダウンタイム | IP 変更 |
|---|---|---|---|
| レガシー Gateway SKU（Standard／HighPerformance）+ Basic IP | ポータルの「Migrate」で Basic→Standard を実施。失敗時はサポートにステートリセット依頼 | 約 5〜10 分 | なし（維持） |
| VpnGw1〜5（非 AZ）+ Basic IP | 同上。移行と同時に AZ SKU（VpnGw*AZ）へ自動昇格する場合あり | 約 5〜10 分 | なし（維持） |
| どうしても停止が取れない | 自動移行を待ち、業務時間外に最小停止で実施。やむを得なければ期末の自動移行に備え入念に監視 | なし〜短時間 | なし（自動移行時） |
| IP を新規に取り直してもよい | ゲートウェイを再作成し、最初から Standard IP を関連付け（構築〜切替） | 切替時に停止 | あり（新 IP） |
Portal での具体手順（アクティブ／パッシブ構成の例）
- Azure Portal で対象の Virtual Network Gateway を開き、左メニューの Configuration → Migrate を選択。
- 前提条件の検証を実行（GatewaySubnet の空き IP、NSG/UDR の非適用、関連更新の停止など）。
- Prepare を実行：新しい Standard IP リソース（候補）や関連更新の準備が行われます。
- Execute を実行：5〜10 分の切断が発生。IP アドレスは同一のまま、Public IP の SKU が Standard に切り替わります。対象によりゲートウェイ SKU が AZ（VpnGw*AZ）へ昇格します。
- トラフィック流量グラフや接続ステータスで 動作検証。問題なければ Commit を実行して確定。
- Portal の Properties → Public IP リソースを開き、SKU が Standard になっていることを確認。ゲートウェイの Overview で SKU（例：VpnGw1AZ）も確認します。
Tips: 検証で異常があれば Abort でロールバックできます（Commit していなければ可）。
PowerShell での具体手順
$rg = "MyResourceGroup"
$gwName = "MyVNetGateway"
# 対象ゲートウェイの取得
$gw = Get-AzVirtualNetworkGateway -Name $gwName -ResourceGroupName $rg
# Basic → Standard IP 移行を指定した Migration パラメータ作成
$param = New-AzVirtualNetworkGatewayMigrationParameter `
-MigrationType UpgradeDeploymentToStandardIP
# 準備（Prepare）
Invoke-AzVirtualNetworkGatewayPrepareMigration -InputObject $gw -MigrationParameter $param
# 実行（Execute）: 5〜10 分の停止が発生
Invoke-AzVirtualNetworkGatewayExecuteMigration -InputObject $gw
# 動作検証後、確定（Commit）
Invoke-AzVirtualNetworkGatewayCommitMigration -InputObject $gw
# 必要に応じてロールバック（Commit 前のみ）
# Invoke-AzVirtualNetworkGatewayAbortMigration -InputObject $gw
「Prepare」が失敗する主な原因と実務対処
| 症状／メッセージ | 想定原因 | 現場で効く対処 |
|---|---|---|
CannotContinueMigrateGatewayWithIncorrectState「Current state is Abort, cannot Prepare」など | 過去の中断で Migration ステートが Abort のまま残留 | サポートにチケットを発行し、Migration ステートのリセットを依頼。前後でユーザー側の並行更新（接続プロパティ変更等）を控える |
| ポータルに Migrate タブが表示されない／押せない | 機能ロールアウト未完、構成未対応、前提未充足 | 最新の Az モジュール／CLI で再検証、リージョンの提供状況を確認。表示されるまで待機 or 代替手段を計画 |
| 検証は成功するが Execute で「An error occurred」 | GatewaySubnet の空き不足、裏側の更新競合、既知の一時不具合 | GatewaySubnet の空きを 3 アドレス以上確保（/27 以上推奨、複数プレフィックスで拡張）。NSG/UDR をゲートウェイサブネットに適用していないか確認。数十分おいて再実行 |
| Active-Active 構成で実行できない | ツールの適用範囲外（時期依存） | サポートに移行可否を確認し、不可なら再作成方式を検討（新 Standard IP／新ゲートウェイ → 切替） |
安全にやり切るためのチェックリスト
事前チェック
- GatewaySubnet：/27 以上かつ 空き IP が 3 以上
- ゲートウェイ／接続の ProvisioningState = Succeeded を確認（長時間の更新処理が走っていない）
- ゲートウェイサブネットに NSG/UDR を適用していない
- オンプレ側ファイアウォールの許可設定に IP の不変を前提にしている場合、ツール移行（IP 維持）を選択。再作成方式は避ける
- 業務影響を避けるため、Execute は業務時間外に実施
実施中のポイント
- Prepare → Execute の間に 接続設定・ゲートウェイ設定の変更を行わない
- Execute 後は トンネルの Ingress/Egress グラフで通信復旧を確認してから Commit
- 異常時は Abort（Commit 前に限る）で安全にロールバック
実施後の確認
- Portal の Properties → Public IP リソースで SKU: Standard を確認
- ゲートウェイ Overview の SKU（例：VpnGw1AZ）を確認
- 監視とアラート（接続ダウン、トンネル閾値、CPU/スループット）を通常運用へ復帰
「自動移行」と「手動移行」の正しい役割分担
自動移行は主に「ゲートウェイ SKU（レガシー → AZ SKU）」の整理を Microsoft 側で無停止または最小影響で行う取り組みです。これに対し、Public IP の Basic → Standard は、運用都合（FW 許可・監視など）を踏まえて 管理者がタイミングを選んで実行するのが原則です。したがって、今回のように「Prepare が通らない」ケースは、自動移行を待っても解消しない（IP は自動では上がらない／上がらない場合がある）と考えるべきです。計画停止を確保したうえで、Migrate タブからの顧客主導移行を完了させることが重要です。
どうしても早期に Basic IP を解消したい場合の選択肢
- ポータル移行（推奨）：IP 不変。停止は 5〜10 分。最も低リスク。
- 再作成（新 Standard IP）→ 切替：ダウンタイムは切替時に限定できるが、IP が変わるため FW 許可や接続先設定の更新が必要。
- サポート依頼：ステート不整合や機能ロールアウト未完で詰まる場合の 最後の一押し。再実行のタイミングやバックエンド対応をアドバイスしてもらう。
よくある誤解と補足
- Q：「自動移行があるなら、IP も自動で Standard になるのでは？」
A：ゲートウェイ SKU の自動移行と、Public IP の SKU 変更は別軸です。IP が自動で上がらない場合があるため、ポータルでの確認と必要に応じた移行の実施が必要です。 - Q：「/27 に広げたのに失敗する」
A：要件は「/27 以上」だけでなく、直近のサブネット内に 3 アドレス以上の空きが必要です。複数プレフィックスで空きを確保してから再実行してください。 - Q：「Prepare が毎回同じエラーで止まる」
A：内部ステートの残留や裏側のロックが疑われます。Abort → 数十分待機 → Prepare の再試行で解消しない場合、サポートでステートリセットを依頼するのが最短です。 - Q：「最新の Az PowerShell で警告が出る」
A：Migrate*系の一部はプレビュー／段階提供に伴い注意書きが表示されることがあります。Portal の Migrate 画面の指示を優先してください。
現場向けまとめ
- 焦って何度も Prepare しない。まずは Migrate タブの提供状態と前提条件を満たすことに集中。
- レガシー SKU の自動移行は任せる。そのうえで、Basic IP の Standard 化は自分たちで計画停止を確保して実行。
- IP を変えないならツール移行一択。再作成は早いが IP 変更と付随作業が重い。
- 詰まったらサポートへ。CannotContinueMigrateGatewayWithIncorrectState などは内部ステートのリセットが近道。
チェックリスト（コピペ用）：
- [ ] GatewaySubnet は /27 以上で、空き IP が 3 以上ある
- [ ] ゲートウェイ／接続が Succeeded で安定している
- [ ] ゲートウェイサブネットに NSG/UDR を適用していない
- [ ] 業務時間外に 10 分の停止ウィンドウを確保した
- [ ] Execute 後にトラフィック復旧を確認してから Commit する手順と係を決めた
- [ ] 失敗時のエスカレーション先（Azure サポート）を準備した
以上を踏まえ、今すぐやるべきことは「Migrate タブの確認 → 前提充足 → 小さく 1 本の接続から移行検証 → 本番計画」――この順です。無理に手動 Prepare を繰り返すより、自動移行の役割と自分たちが責任を持つ移行（Basic IP → Standard）を切り分け、期限内に着実に終わらせるのが最短ルートです。
コメント