オンプレ .NET アプリの Azure 移行完全ガイド

オンプレミスで稼働している .NET アプリを Azure へ移行するプロジェクトは、単なるサーバーの引っ越しではなく、アセスメント・移行戦略の選定・ランディングゾーン整備・IaC と CI/CD・監視・コスト最適化までを含む一連のモダナイゼーションです。本稿では、既存の .NET 資産を Azure 上で安全かつ持続的に運用できる状態へ持っていくための全体像を、実務の順序に沿って整理します。移行と同時に .NET を最新版（.NET 10 LTS）へ揃えておくと、後述するコンテナ化・サーバーレス・マネージドサービスとの相性が大きく向上します。

移行の全体像

Azure 移行は大きく「評価（Assess）」「移行（Migrate）」「最適化（Optimize）」の 3 フェーズで進みます。評価で現状の資産と依存関係を把握し、アプリごとに移行戦略を決め、ランディングゾーン（ネットワーク・ID・ガバナンスの土台）を整えたうえで段階的に移していきます。移行後は監視データをもとに SKU やスケール設定を見直し、コストとパフォーマンスを継続的に調整します。いきなり全システムを一括で切り替えるのではなく、影響範囲の小さいアプリから移し、知見を貯めながら本命システムに進むのが現実的です。

オンプレから Azure への移行戦略の使い分け — ワークロードに応じてリホスト・リファクタ・リアーキテクトを使い分ける。

アセスメント

最初に行うのは棚卸しと依存関係の可視化です。Azure Migrate を使うと、オンプレのサーバー群を検出してスペック・稼働状況・依存関係マップを収集し、Azure 上での想定コストや適切な移行先を推定できます。エージェントレスの依存関係分析でサーバー間の通信を可視化しておくと、切り離せる単位と一緒に移すべき単位が見えてきます。

アプリ単位では、対象の .NET ランタイム（.NET Framework か .NET 8/10 か）、外部依存（Windows 認証、レジストリ、ローカルファイル、COM、メッセージキュー）、データベースのバージョンと容量を洗い出します。ここで .NET Framework 依存が残っている場合は、移行と並行して .NET 10 への引き上げを検討します。詳細は.NET モダナイゼーション完全ガイドで扱う考え方が土台になります。

移行戦略の整理（5R 的アプローチ）

アプリごとに、投資対効果と改修許容度に応じて移行方式を選びます。代表的な選択肢を整理します。

リホスト（リフト＆シフト）

コードにほぼ手を入れず、動く状態のまま移します。Windows 依存が強い、あるいは短期で移し切りたいケースに向きます。移行先としては、仮想マシン（Azure VM）にそのまま載せる方法、ASP.NET アプリを Azure App Service へ持ち込む方法、コンテナ化済みなら Azure Container Apps へ載せる方法があります。App Service は OS・ランタイム・パッチをマネージドで面倒を見てくれるため、VM に比べて運用負荷が下がります。

リファクタ（コンテナ化）

アプリを大きく作り変えずにコンテナ化し、可搬性とスケーラビリティを得るアプローチです。.NET はマルチステージビルドで小さなイメージを作りやすく、最新 .NET なら Native AOT で起動時間とメモリを削れます。コンテナ化しておくと、後段の Container Apps や AKS への展開がそのまま活きます。

# SDK-style プロジェクトをそのままコンテナイメージ化
dotnet publish -c Release /t:PublishContainer

リアーキテクト

より深くクラウドネイティブへ寄せる方式です。マイクロサービス化して AKS や Azure Container Apps に載せる、イベント駆動やバッチ処理を Azure Functions のサーバーレスに切り出す、データ層を Azure SQL Database や Azure Database for PostgreSQL などのマネージド DB へ移す、といった変更を伴います。運用負荷とスケール効率が大きく改善する一方、改修コストは最も高いため、コアで長く使うシステムから優先的に適用します。マイクロサービス化の具体はAzure Container Apps で実現するマイクロサービスやKubernetes で実現するマイクロサービス完全ガイドが参考になります。

ランディングゾーンとネットワーク

個別アプリを移す前に、組織全体の土台となるランディングゾーンを用意します。サブスクリプションとリソースグループの分割方針、命名規則、タグ、Azure Policy によるガードレールを先に決めておくと、後からの統制コストを抑えられます。ネットワークはハブ＆スポーク構成が基本で、共有のハブ（ファイアウォール、DNS、ゲートウェイ）にスポークとなる各ワークロード用 VNet を接続します。オンプレとは ExpressRoute または VPN でつなぎ、段階移行中はハイブリッド接続でオンプレとクラウドを併存させます。PaaS サービスへは Private Endpoint 経由でアクセスし、公開エンドポイントを絞ります。

ID とシークレット管理

認証基盤は Microsoft Entra ID に集約します。オンプレの Windows 認証（Active Directory）に依存していたアプリは、Entra ID ベースの認証へ置き換えるのが移行の重要ポイントです。アプリからほかの Azure リソース（DB、Storage、Key Vault）へアクセスする際は、接続文字列に資格情報を埋め込まず Managed Identity を使います。これにより、コードや構成ファイルからシークレットを排除できます。

どうしても必要なシークレット（外部 API キーなど）は Azure Key Vault に保管し、Managed Identity 経由で取得します。.NET からは次のように、資格情報を持たずにアクセスできます。

var client = new SecretClient(
    new Uri("https://my-vault.vault.azure.net/"),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync("Db--ConnectionString");

設計の詳細はAzure Key Vault で実現するセキュアなシークレット管理で解説しています。

IaC と CI/CD

インフラは手作業のポータル操作ではなく Bicep でコード化し、レビューとバージョン管理の対象にします。環境（開発・ステージング・本番）の差異はパラメータで吸収し、同一テンプレートから再現可能な形で展開します。

param location string = resourceGroup().location
param appName string

resource plan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: '${appName}-plan'
  location: location
  sku: { name: 'P1v3', tier: 'PremiumV3' }
}

resource site 'Microsoft.Web/sites@2024-04-01' = {
  name: appName
  location: location
  properties: { serverFarmId: plan.id, httpsOnly: true }
  identity: { type: 'SystemAssigned' }
}

Bicep の設計・運用はAzure Bicep で実現する Infrastructure as Codeにまとめています。アプリのビルドとデプロイは GitHub Actions や Azure Pipelines でパイプライン化し、認証はシークレットではなく OIDC（フェデレーション資格情報）で行うのが現在の推奨です。IaC の適用とアプリのデプロイを同じパイプラインに載せることで、インフラとコードのバージョンが揃った状態を保てます。

監視とオブザーバビリティ

移行後の健全性を測るため、監視は初期段階から組み込みます。Application Insights（Azure Monitor の一部）を使うと、リクエストのレイテンシ・失敗率・依存関係呼び出し・例外を自動収集でき、分散トレースでサービス間の遅延も追えます。.NET では OpenTelemetry ベースの計装が標準的になっており、最小限の設定でテレメトリを送れます。ログ・メトリクス・トレースを Log Analytics ワークスペースに集約し、アラートとダッシュボードを整えておくと、切り替え直後の異常検知が容易になります。

コスト最適化

クラウドは使った分だけ課金されるため、設計次第でコストは大きく変わります。基本方針を整理します。

オートスケール — 負荷に応じてインスタンス数を増減させ、ピークに合わせた過剰なプロビジョニングを避ける。Container Apps や App Service はスケールルールで需要追従できる。
適切な SKU の選定 — Azure Migrate の推定や監視データをもとに右サイジングし、過大なプランを避ける。定常負荷が読めるワークロードは Reserved Instances や Savings Plan で単価を下げる。
サーバーレスの活用 — 断続的・イベント駆動の処理は Azure Functions の従量課金プランに寄せ、アイドル時のコストをゼロに近づける。Container Apps の scale-to-zero も同様に有効。

段階移行の進め方とデータ移行

移行は一括ではなく、機能単位・アプリ単位で段階的に進めます。フロントにリバースプロキシ（YARP や Azure Application Gateway）を置き、ストラングラーフィグパターンでトラフィックを少しずつ新環境へ寄せると、問題があっても切り戻しやすくなります。

データ移行は最も慎重を要する工程です。ダウンタイムを最小化するには、Azure Database Migration Service などを使ってオンプレ DB から Azure のマネージド DB へ継続的レプリケーションを張り、差分が追い付いた時点でカットオーバーするオンライン移行が有効です。移行前に必ず整合性チェックとロールバック手順を用意し、カットオーバー当日は接続文字列の切り替えと Private Endpoint 経由の疎通を事前に検証しておきます。書き込みの二重化期間を設けるか、短時間の読み取り専用ウィンドウを設けるかは、許容ダウンタイムに応じて選択します。

まとめ

Azure 移行の成否は、アセスメントでどれだけ現状と依存関係を正確に把握できるか、そしてアプリごとに適切な移行戦略（リホスト・リファクタ・リアーキテクト）を選べるかに大きく左右されます。ランディングゾーン・Entra ID / Managed Identity・Key Vault で土台を固め、Bicep と CI/CD で再現性を担保し、Application Insights で可観測性を確保したうえで、段階移行とオンラインデータ移行でリスクを抑えるのが定石です。移行と同時に .NET を最新版へ揃えておくと、コンテナ化・サーバーレス・マネージドサービスの恩恵を最大限に受けられます。

エンハンスド株式会社では、オンプレから Azure へのクラウド移行を、設計から実行まで支援しています。