Azure App Serviceの.NET移行で最初に押さえるべき結論は、既存アプリが突然動かなくなるような破壊的変更ではなく、オンプレミスIIS上のASP.NET/.NET WebアプリをAzure App Serviceへ移行するための公式リソースとツール導線が整理された情報だという点です。
管理者や開発者が今すぐ確認すべきことは、アプリの棚卸し、Azure Migrateによる移行評価、App ServiceプランやSKUの選定、アプリ設定・接続文字列・認証・ネットワーク・監視の移行可否です。特に複数のIISサーバーに分散したASP.NETアプリを扱っている組織では、単体移行ではなくAzure Migrateを使った大規模な検出・評価・移行を前提に計画を見直す価値があります。Microsoft Learnの対象ページは、.NET Webアプリを検出、評価し、コンテンツとサポートされる構成をApp Serviceへ移行するためのツール群を説明しています。(Microsoft Learn)
Azure App Serviceの「Migrate .NET Apps to Azure App Service」は何が変わるのか
今回のポイントは、Azure App Serviceの新機能追加というより、.NETアプリ移行の入口が「ツール別」から「移行シナリオ別」に整理されていることです。
Microsoft Learnの現行ソースでは、対象ページのメタデータがms.date: 06/02/2026に更新されており、直近のGitHub差分ではApp Service Migration AssistantやPowerShellスクリプトのダウンロードリンクが短縮URLへ更新されています。2026年5月下旬の更新情報として追っている場合も、実務では最新版の公式ページとダウンロードリンクを基準に確認するのが安全です。(GitHub)
| 観点 | 変更・整理された内容 | 実務への影響 |
|---|---|---|
| 移行対象の整理 | オンプレミスの.NET Webアプリを発見、評価、移行するためのツールがシナリオ別に整理された | まず「単体移行」か「大規模移行」かを判断しやすくなる |
| 大規模移行 | Azure Migrateを使い、複数IISサーバー上のASP.NET Webアプリをまとめて評価・移行する流れが前面に出ている | 複数部門・複数サーバーのIIS棚卸しをAzure Migrate中心に進めるべき |
| ツールリンク | Migration AssistantやPowerShellスクリプトのリンクが更新されている | 既存の手順書、社内Wiki、CI/CDジョブに古いURLが残っていないか確認が必要 |
| コンテナー移行 | .NET Frameworkアプリの特殊な依存関係がある場合、Windows Containersでの移行も選択肢になる | GAC依存、OS依存、標準App Serviceで吸収しにくいアプリはコンテナー化も検討する |
重要なのは、「Azure App Serviceへ移行すればすべて自動で解決する」と考えないことです。Azure Migrateの評価は移行準備状況やブロッカー、修復ガイダンス、推奨製品、ホスティングコストを把握するための入口であり、移行後の性能検証や運用設計まで代替するものではありません。(Microsoft Learn)
対象になるアプリと担当者
対象になるのは、主にオンプレミスまたは仮想化環境のIISで稼働しているASP.NET Webアプリです。Azure Migrateでは、VMware環境上のIISサーバーにあるASP.NET Webアプリを検出し、Azure App Serviceへの移行準備状況を評価できます。Microsoft Learnでは、単体のASP.NET Webアプリ、単一IISサーバー上の複数アプリ、複数オンプレミスIISサーバーにまたがる複数アプリといったシナリオが区別されています。(Microsoft Learn)
管理者・開発者・運用担当で見るべきポイントは異なります。
| 担当者 | 主な確認ポイント | 具体的な作業例 |
|---|---|---|
| インフラ管理者 | App Serviceプラン、SKU、リージョン、ネットワーク、DNS、TLS | ターゲットリージョン、VNet統合、Private Endpoint、カスタムドメインの設計 |
| アプリ開発者 | .NETランタイム、IIS依存、Web.config、接続文字列、認証方式 | App Serviceで動かないIIS設定やローカル依存の洗い出し |
| セキュリティ担当 | シークレット管理、認証、通信経路、監査ログ | Key Vault参照、Microsoft Entra認証、診断ログ、アクセス制限の確認 |
| 運用担当 | 監視、ヘルスチェック、障害時切り戻し、デプロイ方式 | Application Insights、Health Check、デプロイスロット、アラート設定 |
すでにAzure App Service上で稼働している.NETアプリは、このページ更新だけで直ちに構成変更が必要になるわけではありません。ただし、社内の移行手順書でApp Service Migration AssistantやPowerShellスクリプトを参照している場合は、公式の最新リンクに更新しておくべきです。(GitHub)
移行方式は「規模」と「依存関係」で選ぶ
.NETアプリのAzure App Service移行では、最初に移行方式を決める必要があります。判断基準は、アプリ数、IISサーバー数、依存関係、ネットワーク要件です。
| 状況 | 推奨される移行アプローチ | 判断基準 |
|---|---|---|
| 複数IISサーバーに多数のASP.NETアプリがある | Azure Migrateによる検出・評価・大規模移行 | サーバー単位ではなく、アプリ群として棚卸ししたい場合 |
| 単一IISサーバー上のアプリを移したい | App Service Migration AssistantまたはPowerShellスクリプト | 小規模移行、検証環境、段階移行に向いている |
| .NET FrameworkアプリにGACやOS依存がある | App Containerization ToolでWindows Containers化 | 標準のApp Serviceコード実行環境では吸収しにくい依存がある場合 |
| アプリを大きく作り直す予定がある | 移行前または移行後にモダナイズを分離して計画 | 移行とリファクタリングを同時に行うとリスクが増える |
| 社内DBや閉域ネットワーク依存が強い | ネットワーク設計を先に固めてから移行 | VNet統合、Private Endpoint、DNS、名前解決を先に検証する |
Azure App Service自体は、.NET、Java、Node.js、Python、PHPなどのWebスタックやカスタムコンテナーをサポートするマネージドなホスティング基盤です。標準のApp Serviceにそのまま載せるのか、Windows Containersとして動かすのかは、アプリのIIS依存やOS依存を見て決める必要があります。(Microsoft Learn)
Azure Migrate評価で必ず見るべき項目
Azure MigrateのApp Service評価は、オンプレミスWebアプリのクラウド移行準備状況、リスク、コストの目安を確認するためのものです。評価は構成データに基づいて行われ、Webアプリのパフォーマンスデータは収集されません。そのため、評価結果が「Ready」でも、負荷試験や本番相当の動作確認は別途必要です。(Microsoft Learn)
評価結果は、主に次のように読みます。
| 評価結果 | 意味 | 次にやること |
|---|---|---|
| Ready | App Service移行を妨げる互換性問題が見つかっていない | 検証環境へ移行し、設定・性能・監視を確認する |
| Ready with conditions | 致命的ではないが、注意すべき非互換や修正事項がある | 警告内容と修復ガイダンスを確認し、移行可否を明示的に判断する |
| Not ready | 移行をブロックする互換性問題がある | コード修正、構成変更、コンテナー化、VM継続利用などを比較する |
| Unknown | 検出中、または検出エラーにより評価できない | Azure Migrate appliance、権限、ネットワーク、IIS検出条件を確認する |
Azure Migrateの統合移行フローでは、評価済みのWebアプリを使って移行を進めます。公式チュートリアルでは、Readyのアプリは移行対象として既定でタグ付けされ、Ready with conditionsのアプリも「Will migrate?」でYesを選択することで移行対象にできます。(Microsoft Learn)
移行前に注意すべき公式上の制限
Azure Migrateを使ったApp Service移行には、事前に知っておくべき制限があります。ここを見落とすと、評価後や本番移行直前に計画を組み直すことになります。
| 確認項目 | 注意点 | 実務での対策 |
|---|---|---|
| App Serviceプラン数 | 1回の移行で選択できるApp Serviceプランは最大5つ | 部門・環境・重要度ごとに移行単位を分ける |
| 既存App Serviceプラン | 統合移行フローでは既存App Serviceプランの選択がサポートされていない | 移行ウィザード内で作成されるプラン名、SKU、配置を事前確認する |
| アプリサイズ | 仮想ディレクトリ内のコンテンツを含め、移行対象Webアプリは最大2GB | ログ、アップロードファイル、一時ファイルを事前に分離する |
| UNCディレクトリ | UNCディレクトリのコンテンツ移行はサポートされていない | Azure Files、Blob Storage、アプリ側の保存先変更を検討する |
| VNet統合 | 移行フローではVNet統合シナリオがサポートされていない | 移行後のネットワーク構成として別途設計・検証する |
| IISサーバー要件 | IIS WebサーバーをホストするサーバーにWindows PowerShell 4.0が必要 | 移行対象サーバーのPowerShellバージョンと実行権限を確認する |
これらの制限は、移行作業そのものよりも計画段階で効いてきます。たとえば、アプリのアップロードファイルをIISサーバーのローカルディスクやUNC共有に置いている場合、App Serviceへ移す前に保存先を再設計しておかないと、移行後にファイル参照や書き込み処理で障害が起きます。(Microsoft Learn)
IISアプリで失敗しやすい設定差分
オンプレミスIISからAzure App Serviceへ移行する場合、コードそのものよりもIIS設定の差分でつまずくことがあります。特に次の項目は、開発者だけでなく管理者も一緒に確認してください。
| 項目 | 失敗しやすい理由 | 確認方法 |
|---|---|---|
| アプリケーションプール | App Serviceアプリでは複数のアプリケーションプール構成をそのまま持ち込めない場合がある | IIS上のサイト、仮想アプリ、アプリプール対応を棚卸しする |
| アプリプールID | LocalSystemやSpecificUserなど、App ServiceでサポートされないID種別がある | ApplicationPoolIdentityへ寄せられるか確認する |
| 認証方式 | オンプレミスIISとApp Serviceではサポートされる認証構成が異なる | Windows認証、匿名認証、カスタム認証、Entra ID移行方針を確認する |
| Web.config | App Service側のアプリ設定がWeb.configやappsettings.jsonの値を上書きする | 本番シークレットをApp Service設定またはKey Vaultへ分離する |
| 仮想ディレクトリ | パス構成がIIS前提になっているとApp Service上で崩れる | Path mappings、コンテンツ配置、相対パスを検証する |
Microsoftのトラブルシューティング資料では、複数アプリケーションプール、未サポートのアプリプールID、オンプレミスIISとApp Serviceの認証方式差分が、App Service評価時の代表的な問題として挙げられています。(Microsoft Learn)
App Serviceの設定で移行前に確認するポイント
Azure App Serviceでは、アプリ設定が環境変数としてアプリケーションに渡されます。ASP.NETやASP.NET Coreでは、App Service側で設定した値がWeb.configやappsettings.jsonの値を上書きできます。開発環境用の値はコード側に残し、本番DBのパスワードなどのシークレットはApp Service設定やKey Vault参照へ分離するのが基本です。(Microsoft Learn)
移行前に最低限確認すべき設定は次の通りです。
| 設定 | 確認内容 | 例 |
|---|---|---|
| アプリ設定 | 環境ごとに変える値をApp Service側へ移す | ASPNETCORE_ENVIRONMENT、外部APIのベースURL |
| 接続文字列 | DB接続情報をコードやWeb.configに固定しない | Azure SQL、SQL Server、MySQL、Redis |
| Key Vault参照 | パスワードやAPIキーを平文で管理しない | DBパスワード、外部サービスのトークン |
| スロット設定 | ステージングと本番で値が入れ替わると困る設定を固定する | 本番DB接続先、認証クライアントシークレット |
| 一般設定 | 64-bit、WebSockets、Always On、HTTPS Only、最小TLSを確認する | SignalR利用時のWebSockets、常時起動が必要なアプリ |
App Serviceの一般設定では、32-bit/64-bit、FTP状態、HTTPバージョン、WebSockets、Always On、セッションアフィニティ、HTTPS Only、最小TLSバージョンなどを構成できます。Always Onが無効な場合、一定時間リクエストがないとアプリがアンロードされ、次回アクセス時の待ち時間が増える可能性があります。(Microsoft Learn)
.NETランタイムのサポート期限も同時に確認する
.NETアプリをAzure App Serviceへ移行するなら、移行可否だけでなくランタイムのサポート期限も確認してください。App Serviceは言語コミュニティのサポートライフサイクルに従い、サポート終了後もアプリがただちに停止するとは限らないものの、そのランタイムに対するセキュリティパッチや関連サポートは提供できなくなります。(Microsoft Learn)
執筆時点の.NET公式ダウンロードページでは、.NET 10.0が最新のLTSとして掲載され、.NET 8.0と.NET 9.0はいずれも2026年11月10日がサポート終了予定、.NET 6.0や.NET 7.0はすでにサポート終了済みとして扱われています。移行計画では、単に「App Serviceで動くか」ではなく、「移行後もサポートされるランタイムか」を確認することが重要です。(Microsoft)
ただし、ランタイム更新を移行作業と同時に行うと、障害発生時に原因の切り分けが難しくなります。実務では、次のどちらかに分けると安全です。
| 方針 | 向いているケース | 注意点 |
|---|---|---|
| 先に現行ランタイムのままApp Serviceへ移す | 移行期限が近い、コード変更リスクを抑えたい | サポート期限が近い場合、移行後すぐにランタイム更新計画が必要 |
| 先にランタイムを更新してから移す | テスト期間を確保できる、コード保守体制がある | 移行と改修のスコープを明確にしないと工数が膨らむ |
| コンテナーで依存関係ごと移す | .NET Framework依存やGAC依存が強い | コンテナーイメージの更新、脆弱性管理、起動時間を運用に組み込む |
ネットワーク要件は移行後に回さない
App Service移行で後回しにされがちなのがネットワークです。オンプレミスIISでは同一LAN内のDB、ファイルサーバー、SMTP、社内APIに簡単につながっていたとしても、App Service移行後は名前解決、送信経路、ファイアウォール、Private Endpoint、VNet統合を設計し直す必要があります。
Azure App ServiceのVNet統合は、アプリからVNet内またはVNet経由のリソースへアクセスするための機能です。ただし、VNet統合だけでアプリへのインバウンドアクセスがプライベート化されるわけではありません。アプリをプライベートネットワークからのみアクセスさせたい場合は、Private Endpointなど別の設計が必要です。(Microsoft Learn)
確認すべきネットワーク項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
| 送信先DB | Azure SQL、SQL Server、社内DBのどれに接続するか |
| 名前解決 | プライベートDNSゾーン、オンプレミスDNS、カスタムDNSのどれを使うか |
| 送信経路 | VNet統合、NAT Gateway、ExpressRoute、VPNの要否 |
| 受信制御 | Public access、Access restrictions、Private Endpointの方針 |
| 証明書 | カスタムドメイン、TLS/SSLバインド、証明書更新の運用 |
| シークレット取得 | Key Vault参照を使う場合、Key Vaultへの経路と権限を確認する |
ネットワークは「移行後につながらなかったら直す」ではなく、評価段階で依存先リストを作り、検証環境で接続試験まで終えておくべき領域です。
デプロイは本番直投入ではなくスロットを使う
Azure App Serviceへの移行後は、デプロイ方式も見直してください。App ServiceではStandard、Premium、IsolatedレベルのApp Serviceプランでデプロイスロットを利用できます。スロットは独自のホスト名を持つ稼働中のアプリで、アプリのコンテンツや構成要素を本番スロットと入れ替えられます。(Microsoft Learn)
実務では、移行検証用のstagingスロットにアプリを配置し、次の確認を終えてから本番へスワップする流れが安全です。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | stagingスロットへ移行・デプロイ | アプリ起動、ログ出力、環境変数、接続文字列 |
| 2 | スモークテスト | ログイン、主要画面、API、DB更新、外部連携 |
| 3 | ウォームアップ | 初回アクセス遅延、キャッシュ、JIT、Health Check |
| 4 | 本番スワップ | DNS、TLS、認証リダイレクト、Cookie、セッション |
| 5 | 切り戻し確認 | 問題発生時に直前の正常スロットへ戻せるか |
Microsoftのデプロイベストプラクティスでも、本番ビルドを直接本番スロットへ継続デプロイするのではなく、非本番スロットへデプロイして検証し、準備ができたら本番へスワップする考え方が推奨されています。(Microsoft Learn)
移行後は監視とヘルスチェックまで設定して完了
移行は、アプリが起動した時点では完了ではありません。App Service移行後は、診断ログ、Application Insights、Health Check、Azure Monitorアラートまで設定して、障害の検知と原因調査ができる状態にする必要があります。
App Serviceでは、診断と問題解決、組み込み診断ログ、Health Check、Application Insightsを組み合わせて監視できます。ASP.NET Core、ASP.NET、Java、Node.js、PythonではApplication Insightsによる可観測性の有効化が推奨されています。(Microsoft Learn)
Health Checkは、指定したパスに対して1分間隔でpingを行い、正常でないインスタンスをロードバランサーから外したり、継続的に異常なインスタンスを置き換えたりするための機能です。ヘルスチェック用のパスは、単に200 OKを返すだけでなく、DBやメッセージングなどアプリの重要依存先を確認する設計にすると、実運用で役立ちます。(Microsoft Learn)
移行後の最低限の監視項目は次の通りです。
| 監視項目 | 見るべき理由 |
|---|---|
| HTTP 5xx | 移行後の例外、認証失敗、依存先エラーを早期検知する |
| 応答時間 | App Serviceプランのサイズ不足、DB遅延、コールドスタートを把握する |
| CPU・メモリ | SKUやインスタンス数が適切か判断する |
| 依存関係 | DB、外部API、ストレージ、Key Vaultの遅延や失敗を追う |
| Health Check | 異常インスタンスを切り離し、可用性を高める |
| ログ容量 | ファイルログの保持期間や出力先を管理する |
管理者と開発者が移行前に作るべきチェックリスト
移行計画では、ツールの実行手順だけでなく、判断結果を残すチェックリストを作ることが重要です。特に複数アプリをまとめて移行する場合、評価結果、修正方針、移行方式、移行順序が曖昧なままだと、後工程で手戻りが増えます。
| 分類 | チェック項目 | 完了条件 |
|---|---|---|
| 棚卸し | IISサイト、アプリプール、バインド、証明書、仮想ディレクトリを洗い出したか | アプリ一覧と依存関係一覧がある |
| 評価 | Azure MigrateでApp Service評価を実行したか | Ready、Ready with conditions、Not ready、Unknownを分類済み |
| 移行方式 | コード移行、Migration Assistant、PowerShell、コンテナー化を選んだか | アプリごとに方式が決まっている |
| 設定 | App settings、Connection strings、Key Vault参照を整理したか | 環境別の設定表がある |
| ネットワーク | DB、社内API、ファイル共有、名前解決を検証したか | staging環境から接続確認済み |
| セキュリティ | 認証方式、TLS、アクセス制限、RBACを確認したか | 本番相当の認証・認可でテスト済み |
| 展開 | デプロイスロットと切り戻し手順を用意したか | スワップとロールバックを検証済み |
| 監視 | Application Insights、Health Check、アラートを設定したか | 障害検知と調査の導線がある |
よくある判断ミス
Azure App Serviceへの.NET移行では、次のような判断ミスが起きがちです。
「Readyだから本番移行してよい」と考えるのは危険です。Azure Migrateの評価は構成ベースであり、性能や業務シナリオ全体の正しさを保証するものではありません。必ずstaging環境で負荷、認証、外部連携、ログ、監視を確認してください。(Microsoft Learn)
「IISの構成をそのまま持ち込める」と考えるのも失敗のもとです。アプリケーションプール、認証、ローカルファイル、UNC共有、パス構成はApp Service上で差分が出やすいため、コードより先に構成を棚卸しする必要があります。(Microsoft Learn)
「ネットワークは移行後に調整すればよい」と考えると、DB接続や社内API接続で詰まりやすくなります。App ServiceのVNet統合は主にアウトバウンド接続のための機能であり、インバウンドのプライベートアクセスとは別物です。(Microsoft Learn)
「本番スロットへ直接デプロイする」運用も避けるべきです。App Serviceでは、非本番スロットで検証してから本番へスワップすることで、停止時間を抑え、問題発生時の切り戻しもしやすくなります。(Microsoft Learn)
まず取るべき次の行動
Azure App Serviceの.NET移行を進めるなら、最初にやるべきことは明確です。
まず、IIS上のASP.NET/.NET Webアプリを棚卸しし、アプリ数、サーバー数、ランタイム、DB、認証、ファイル保存先、外部連携を一覧化します。次に、Azure MigrateでApp Service評価を実行し、Ready、Ready with conditions、Not ready、Unknownに分類します。そのうえで、アプリごとに「App Serviceへコード移行」「Migration AssistantまたはPowerShellで移行」「Windows Containers化」「VM継続または再設計」を判断してください。
最後に、移行手順書には必ず、App settings、接続文字列、Key Vault、VNet統合、DNS、TLS、デプロイスロット、Application Insights、Health Check、切り戻し手順を含めます。移行ツールを実行するだけではなく、移行後に安全に運用できる状態まで作ることが、Azure App Serviceへの.NET移行を成功させる最大のポイントです。
コメント