レガシー .NET 移行前 診断チェックリスト

レガシーな .NET Framework 資産を .NET 10 へ移行する前に必要なのは、いきなりコードへ手を入れることではなく、現状を体系的に把握することです。対象ランタイム・依存関係・移行ブロッカー・データアクセス・認証・テスト・インフラといった観点を漏れなく棚卸ししておくと、移行方式（リホスト／リファクタ／リアーキテクト）の判断と工数見積りの精度が大きく上がります。本記事は移行着手前に実施すべき診断項目をカテゴリごとにチェックリスト形式でまとめたものです。各項目を「該当する／しない／要調査」で埋めていくことで、移行計画の土台となる現状マップが完成します。

対象ランタイムとフレームワークの把握

まず何が動いているのかを正確に特定します。バージョンが曖昧なまま見積もると後工程で大きく崩れます。

• 各プロジェクトの TargetFrameworkVersion（.NET Framework 4.5 / 4.6.x / 4.7.x / 4.8）を一覧化したか。
• 混在する場合、最も古いバージョンと、それに依存している理由を把握したか。
• プロジェクト形式が旧 MSBuild 形式か SDK-style かを区別したか（SDK-style 化の要否に直結する）。
• 移行先の TFM を net10.0（LTS）に定めたか。Web は net10.0、Windows デスクトップは net10.0-windows を想定したか。
• ソリューション内のプロジェクト数・総行数・アプリケーション種別（Web / API / デスクトップ / バッチ / ライブラリ）を集計したか。

依存関係の棚卸し

移行可否は自前コードよりも依存パッケージの対応状況で決まることが多く、ここが診断の核心です。

• NuGet パッケージを一覧化し、各パッケージが .NET（net10.0 / netstandard2.0）に対応済みか確認したか。
• packages.config 管理のプロジェクトを PackageReference へ移す前提で棚卸ししたか。
• 更新が停止したパッケージ・作者が消えたパッケージについて代替を調べたか。
• サードパーティ製ライブラリ（帳票、PDF、Excel、グリッド系 UI など）の .NET Core 対応版・ライセンス条件を確認したか。
• Native AOT を視野に入れる場合、リフレクションや動的コード生成に依存するライブラリの AOT 互換性を確認したか。

依存とAPIの非互換は手作業で数えず、ツールで機械的に洗い出します。

dotnet tool install -g upgrade-assistant
upgrade-assistant analyze MySolution.sln --target net10.0

Upgrade Assistant（.NET 10 対応済み）は非互換 API と推奨代替を一覧化します。プロジェクト単位の変換には try-convert が使えます。かつての .NET Portability Analyzer（apiport）が担っていた「使用中 API がターゲットで利用可能か」を機械的に照合する考え方は、現在は Upgrade Assistant の分析やアナライザー（CA1416 などのプラットフォーム互換性診断）に引き継がれています。

移行ブロッカーの特定

.NET Framework 固有で .NET へ移植できない、あるいは大幅な書き換えを要する技術要素を先に洗い出します。ここに該当項目が多いほど工数と方式の見直しが必要です。

• ASP.NET Web Forms — .NET には存在しない。Blazor / MVC / Razor Pages への作り替えが必要か判定したか。
• WCF サーバ — サーバ側は CoreWCF、クライアントは System.ServiceModel の対応版で移植可能か確認したか。
• .NET Remoting — .NET に存在しない。gRPC / HTTP API などへの再設計が必要か把握したか。
• 複数 AppDomain 依存 — .NET では単一 AppDomain。分離ロード前提の設計を AssemblyLoadContext やプロセス分離へ置換できるか検討したか。
• System.Web 依存 — HttpContext.Current などグローバル状態への依存箇所を洗い出したか。
• System.Drawing.Common — Windows 専用扱いとなったため、非 Windows 実行なら ImageSharp / SkiaSharp 等への置換を検討したか。
• config / machine.config 依存 — ConfigurationManager や machine.config 前提の構成を appsettings.json と環境変数へ再マッピングできるか確認したか。

データアクセスの診断

データ層は移行時に挙動差異が出やすく、検証工数を左右します。

• Entity Framework 6 の利用箇所を特定し、EF Core 10 への書き換え規模を見積もったか。
• EF6 と EF Core で挙動が異なる箇所（遅延ロード、LINQ のクライアント評価、既定のトラッキング挙動）を検証対象として洗い出したか。
• 生 SQL・ストアドプロシージャ・DB ベンダー固有機能への依存度を把握したか。
• 接続文字列の管理（web.config → 構成 + シークレット管理）の移行方針を決めたか。
• ADO.NET やレガシーな DataSet / DataTable 中心のコードの扱いを判断したか。

認証・認可の診断

• ASP.NET Membership / SimpleMembership 利用箇所を特定し、ASP.NET Core Identity への移行規模を把握したか。
• Forms 認証・machine.config の machineKey 依存を洗い出したか。
• 既存ユーザーのパスワードハッシュ形式を確認し、Identity への移行方式（再ハッシュ／段階移行）を決めたか。
• Windows 認証・Active Directory 連携の要否と移行方式を確認したか。
• 将来的な OpenID Connect / Entra ID などへの寄せ替え可否を検討したか。

テスト・CI/CD・インフラ・運用の準備状況

移行の安全性は、切り替え後の挙動を検証できる仕組みが整っているかに大きく依存します。

• 自動テストのカバレッジと、リグレッション検知に足るテスト資産があるかを評価したか。
• テストが無い中核ロジックについて、移行前に特性化テスト（現状の振る舞いを固定するテスト）を追加できるか検討したか。
• CI/CD パイプラインの有無と、.NET 10 SDK でのビルドへ更新できるかを確認したか。
• ホスティング環境（IIS / オンプレ VM / Azure App Service / Container Apps 等）と、コンテナ化・クラウド移行の方針を確認したか。
• ロギング・監視・APM の現状と、OpenTelemetry ベースの可観測性へ移行する余地を把握したか。
• OS・ミドルウェアのサポート期限と、移行スケジュールとの整合を確認したか。

工数見積りと移行方式の区分

診断結果を集約したら、システム（または機能単位）ごとに移行方式を割り当てて見積もります。以下の 3 区分で切り分けると精度が上がります。

• リホスト — コード変更を最小化して環境だけ移す。ブロッカーが少なく依存が概ね対応済みの資産に適用。工数は小さいが得られる恩恵も限定的。
• リファクタ — SDK-style 化・依存の置換・非互換 API の修正を行い、構造は概ね維持したまま .NET 10 へ載せ替える。多くのビジネスアプリの現実解。
• リアーキテクト — Web Forms・Remoting・複数 AppDomain など重いブロッカーを抱える資産を、設計から作り直す。工数は最大だが、モダンな構成の恩恵を最大化できる。

見積り配分は「分析 6 割、実装 3 割、検証 1 割」を目安にすると、後工程での手戻りを抑えられます。

まとめ

診断の目的は、感覚ではなくデータで移行方式を選べる状態を作ることです。対象ランタイム・依存・ブロッカー・データ・認証・テスト・インフラの各チェック結果を突き合わせ、資産ごとにリホスト／リファクタ／リアーキテクトを割り当てれば、そのまま移行計画とロードマップの骨子になります。診断が終わっていれば、実装フェーズは .NET Framework 4.x から .NET 10 への移行プレイブック の手順に沿って進められます。Web Forms を含む資産は ASP.NET Web Forms から Blazor への移行ガイド も併せて参照してください。

このテーマの全体像は .NET モダナイゼーション完全ガイド にまとめています。

エンハンスド株式会社では、レガシー資産の診断から移行計画の策定・実行までを一貫して支援しています。

• レガシーシステム モダナイゼーション - レガシー資産を分析し、最新 .NET への安全な移行を支援
• クラウドネイティブ & 移行 - Azure / AWS でクラウドネイティブな設計と移行を支援