目次
.NET Frameworkで構築された業務システムが、静かに行き詰まりつつある。.NET Framework 4.8は最終リリースであり、新機能の追加は今後行われない。Microsoftの開発投資は.NET（旧.NET Core）に完全にシフトしている。
.NET Framework 4.8.1が2022年8月にリリースされたが、これはArm64対応とアクセシビリティ改善が主な変更点だ（出典：Microsoft .NET Framework 4.8.1）。以降はセキュリティ修正と信頼性修正のみが提供される保守モードに入っている。「動いているから問題ない」という判断が、技術的負債を日々積み上げている。
本記事では、.NET Framework/ASP.NETで構築されたシステムを.NET 8/ASP.NET Coreへ段階的に移行する戦略と実践手順を解説する。
ASP.NET移行が避けられない3つのモダナイゼーション要因
「まだサポートされているのに、なぜ移行が必要なのか」。そう考える方もいるだろう。しかし、.NET Frameworkの「サポート」は、OSのライフサイクルに紐づいた受動的なものにすぎない。
新機能の開発停止
.NET Framework 4.8が最終バージョンと公式に宣言されている（出典：Microsoft Learn「.NET Frameworkの新機能」）。C#の新しい言語機能、パフォーマンス改善、新しいAPI。これらはすべて.NET側にのみ追加される。.NET Frameworkにとどまる限り、技術的な恩恵を一切受けられない。
Windows限定という制約
.NET FrameworkはWindows専用だ。コンテナ化する場合もWindows Containerに限定される。クラウドネイティブな運用やLinuxベースのコンテナ環境に対応できない。AWSやAzureでのランニングコストも、Linux環境に比べて割高になる。
開発者の採用難
.NET Frameworkの求人に応募するエンジニアは減少傾向にある。新しい技術を学びたい開発者にとって、将来性のないフレームワークは魅力に乏しい。既存メンバーの退職や異動が発生した際、後任の確保が困難になるリスクがある。
.NET 8への移行で得られる具体的なメリット
移行は手間がかかる。だからこそ、得られるメリットを正確に把握しておく必要がある。
パフォーマンスの大幅な向上
.NET 8では500以上のPR（Pull Request）がパフォーマンス改善に貢献している（出典：Microsoft .NET Blog「Performance Improvements in .NET 8」）。.NET Frameworkからの移行では、レイテンシが2〜6倍改善された事例が報告されている（出典：Hacker News discussion on .NET performance）。LINQ操作で50%以上の高速化、DateTime処理で30%の改善など、コードを変えなくても恩恵を受けられる部分が多い。
クロスプラットフォーム対応
.NET 8はWindows、Linux、macOSで動作する。Linux上でのコンテナ運用が可能になり、Kubernetesとの親和性も高い。インフラコストの削減と運用の柔軟性が得られる。
長期サポート（LTS）
.NET 8は2026年11月までのLTSが保証されている（出典：Microsoft「.NETおよび.NET Coreの公式サポートポリシー」）。定期的にアップグレードするサイクルが確立されており、EOL後に放置される.NET Frameworkとは対照的だ。
ASP.NETからASP.NET Coreへの移行で直面する互換性の課題
移行には技術的なハードルがある。事前に把握しておくことで、計画の精度が上がる。
ASP.NET Web Formsの移行先がない
最大の課題がこれだ。ASP.NET Web FormsにはASP.NET Coreへの直接的な移行パスが存在しない（出典：Microsoft Learn「Migrate from ASP.NET Web Forms to Blazor」）。UIの全面書き換えが必要になる。
移行先の選択肢は主に2つある。
Blazorへの移行。Web Formsと同じサーバーサイドレンダリングのモデルを採用しており、概念的な親和性が高い。ただし、ViewStateやPostBackの仕組みは根本的に異なる。コンポーネント単位での段階的な書き換えが必要だ。
ASP.NET Core MVCへの移行。Web APIとRazor Viewsを組み合わせる構成だ。フロントエンドをReactやVueに分離する選択肢もある。Web Formsからの距離は大きいが、長期的な拡張性は高い。
WCFの代替が必要
WCF（Windows Communication Foundation）はASP.NET Coreでサポートされない。サービス間通信の仕組みを置き換える必要がある（出典：Microsoft Developer Blog「gRPC + ASP.NET Core as a Migration Path for WCFs」）。
| 用途 | WCFの代替技術 | 特徴 |
|---|---|---|
| サービス間通信 | gRPC | バイナリプロトコル、高速、.proto定義 |
| 外部API公開 | REST API（ASP.NET Core Web API） | HTTP/JSON、広い互換性 |
| リアルタイム通信 | SignalR | WebSocket対応、双方向通信 |
| SOAP互換が必要 | CoreWCF | OSSによるWCF互換レイヤー |
CoreWCFを使えばSOAPクライアントとの互換性を維持しながら段階的に移行できる。ただし、CoreWCFは完全なWCF互換ではない点に注意が必要だ。
Entity Framework 6からEF Coreへの移行
EF 6のAPIとEF CoreのAPIは互換性がない。EDMX（XML定義モデル）はEF Coreで廃止されている。Code Firstモデルへの書き換えと、LINQ クエリの動作差異の検証が必要になる。
ASP.NET Coreへの段階的移行｜5ステップのモダナイゼーション戦略
一括移行（ビッグバン方式）は失敗リスクが高い。ストラングラーフィグパターンを適用し、既存システムを稼働させながら段階的に置き換えていく戦略が現実的だ（出典：Microsoft .NET Blog「Incremental ASP.NET to ASP.NET Core Migration」）。
ステップ1: 現行システムの構造を可視化する
移行の第一歩は、現行システムの全体像を正確に把握することだ。ASP.NETアプリケーションは長年の運用で複雑化しているケースが多い。
具体的に把握すべき項目は以下のとおりだ。
- プロジェクト構成と参照関係の全体像
- 使用しているNuGetパッケージの一覧と.NET Core互換性
- Global.asax、Web.config、HttpModuleなどの設定構造
- WCFサービスの有無と通信パターン
- Web Formsページ（.aspx）の数と複雑度
- 外部システムとの連携ポイント（DB、API、ファイル共有）
設計書が最新化されていない場合、ソースコードから構造を読み解く必要がある。この調査を省くと、移行中に想定外の依存関係が発覚し、手戻りが発生する。
ステップ2: 共有ライブラリの.NET Standard化
ビジネスロジック層やデータアクセス層を.NET Standard 2.0に対応させる。.NET Standard 2.0は、.NET Frameworkと.NET Core/.NETの両方から参照できるブリッジとして機能する。
具体的な手順は以下のとおりだ。
クラスライブラリプロジェクトの移行。既存の.NET Framework向けクラスライブラリを.NET Standard 2.0のプロジェクトに変換する。csprojファイルをSDKスタイルに書き換え、ターゲットフレームワークをnetstandard2.0に変更する。
API互換性の確認。.NET Portability Analyzerやdotnet-api-compatツールで、使用しているAPIが.NET Standardに含まれているか確認する。System.Web名前空間のAPIは.NET Standardに存在しない。このAPIに依存している箇所は設計の見直しが必要だ。
マルチターゲット対応。一時的に.NET Framework 4.8とnetstandard2.0の両方をターゲットにすることで、既存システムと新システムの両方から参照できる。
ステップ3: 新規機能をASP.NET Coreで構築する
既存のASP.NETアプリケーションを動かしたまま、新規のAPI・機能をASP.NET Coreで構築する。リバースプロキシ（YARP、IIS URL Rewrite）で、リクエストのルーティングを制御する。
YARPはMicrosoft製のリバースプロキシライブラリだ。URLパスに基づいて、既存のASP.NETアプリとASP.NET Coreアプリにリクエストを振り分けられる。新しいエンドポイントはASP.NET Coreに向け、既存のエンドポイントは従来のASP.NETアプリに流す。
このアプローチの利点は、本番環境で稼働中のシステムを止めずに移行を進められる点にある。新しい部分に問題が発生しても、ルーティングを切り替えるだけで切り戻せる。
「移行対象の構造がわからない」が最大の障壁になっていないか。
SysDockは、AIマルチエージェントがASP.NETのソースコードを解析し、プロジェクト構成・依存関係・外部連携をWord・PPT・React Flowフロー図で可視化する。ソースコード非送信、1週間納品、完全後払い。
ステップ4: 既存機能の段階的な移植
新規機能の構築が安定したら、既存機能をASP.NET Coreに移植していく。優先順位のつけ方が重要だ。
移植の優先順位の考え方。
- 独立性の高いAPI・サービスから着手する。他の機能への依存が少ないものから移植する。
- 変更頻度の高い機能を優先する。頻繁にコード修正が入る箇所は、早期に移行したほうが二重メンテナンスのコストを減らせる。
- Web Formsページは最後に回す。UI書き換えの工数が大きいため、後回しにしてリスクを分散する。
各機能の移植後、リバースプロキシのルーティングを更新し、トラフィックを新しいASP.NET Core側に切り替える。問題が発生すればルーティングを戻すだけで切り戻せる。
ステップ5: テスト戦略と本番切り替え
段階的移行の各ステップで、テストによる動作検証が不可欠だ。
テスト戦略のポイント。
- 移行前にE2Eテストを整備する。既存の動作を保証するテストを先に用意する。移行後の回帰確認に使える。
- 契約テスト（Contract Test）を導入する。API移植時、レスポンス形式が変わっていないことを自動検証する。
- 並行稼動テストを実施する。旧システムと新システムの両方にリクエストを送り、レスポンスを比較する手法だ。移行前後の動作差異を検出できる。
本番切り替えはブルーグリーンデプロイまたはカナリアリリースで段階的に行う。一度にすべてのトラフィックを切り替えず、10% → 30% → 50% → 100%と段階的にトラフィックを移行する。
ASP.NETモダナイゼーション移行で失敗しないための3つの原則
原則1: ビッグバン移行を避ける
DEV Communityの記事でも指摘されているとおり、一度にすべてを切り替えるビッグバン方式は失敗の典型パターンだ（出典：DEV Community「Migrating from .NET Framework to .NET 8: A Complete Strategy Guide」）。ストラングラーフィグパターンを適用し、1機能ずつ移行する。各ステップのリリース間隔は1〜2スプリントが目安だ。
原則2: 移行ツールを活用する
Microsoftは従来、.NET Upgrade Assistantを提供していた。2025年後半にこのツールは非推奨となり、GitHub Copilotアプリモダナイゼーションに置き換えられている（出典：Microsoft Learn「.NETアップグレードアシスタントの概要」）。ただし、GitHub Copilotは有償サブスクリプションが必要だ。レガシーのUpgrade Assistantも引き続き利用可能なため、プロジェクトの規模と予算に応じて使い分ける。
注意点として、自動変換ツールだけで移行が完了することはない。開発者の声として「数百時間の手動修正が必要だった」という報告もある（出典：DevClass「Copilot .Net modernization tool a 'huge downgrade,' devs say」）。ツールはあくまで補助だ。
原則3: 移行前に構造を「見える化」する
繰り返しになるが、構造の把握が移行の成功率を決定する。Global.asaxのライフサイクルイベント、HttpModuleのパイプライン処理、Web.configの設定階層。これらはASP.NET Core では根本的に仕組みが異なる。移行前に全容を把握していなければ、予期せぬ動作差異に悩まされることになる。
依存関係の分析に加え、NuGetパッケージの.NET Core互換性も事前に確認しておく。互換性のないパッケージがある場合、代替ライブラリの選定や自前での実装が必要になる。その工数を計画段階で織り込んでおくことが重要だ。
移行プロジェクトの費用感については、レガシーシステム移行の費用相場の記事で規模別に解説している。レガシーシステムの構造解析やモダナイゼーション戦略の全体像については、レガシーシステム モダナイゼーション戦略の記事も参考にしてほしい。
まとめ
.NET Frameworkからの移行は、もはや「やるかどうか」ではなく「いつやるか」の問題だ。
本記事のポイントを整理する。
- .NET Framework 4.8は最終リリースであり、新機能は追加されない。保守モードに入った技術基盤に、ビジネスの将来を預け続けるリスクを経営層にも正確に伝える必要がある。
- ASP.NET Web FormsにはASP.NET Coreへの直接的な移行パスがない。BlazorまたはASP.NET Core MVCへのUI書き換えが必要だ。WCFもgRPCやREST APIへの置き換えが求められる。
- 移行は5段階で進める。構造の可視化 → .NET Standard化 → 新規機能のASP.NET Core構築 → 既存機能の段階的移植 → テスト・本番切り替え。ストラングラーフィグパターンで、稼働中のシステムを止めずに進める。
- .NET 8への移行でパフォーマンスが2〜6倍改善する可能性がある。クロスプラットフォーム対応によるインフラコスト削減も加味すれば、移行の投資対効果は十分に見込める。
移行を始める前に、まず自社の.NETシステムが「今どうなっているか」を正確に把握すること。その一歩が、プロジェクト全体の成功確率を大きく左右する。
ASP.NETシステムの構造、把握できているか。
SysDockは、AIマルチエージェントがソースコードからプロジェクト構成・依存関係・外部連携を自動解析し、Word・PPT・React Flowフロー図の3点セットで1週間納品する。ASP.NETを含む13言語/FWに対応。ソースコード非送信・完全後払いで、安心して依頼できる。
よくある質問（FAQ）
Q. .NET Framework 4.8はいつサポートが終了しますか？
A. .NET Framework 4.8のサポートはWindowsのライフサイクルに紐づいている。Windows Server 2022のサポート期限は2031年10月14日のため、少なくともその時点まではセキュリティ修正が提供される。ただし、新機能の追加は一切ない。「サポート中」と「開発が活発」はまったく別の話だ。
Q. ASP.NET Web FormsからBlazorへの移行は簡単ですか？
A. 簡単ではない。ViewStateやPostBackの仕組みがBlazorには存在しないため、UI層の全面書き換えが必要になる。ただし、サーバーサイドレンダリングのモデルが共通しているため、概念的には理解しやすい。ページ単位での段階的な移行が可能だ。
Q. 移行にかかる期間の目安は？
A. システム規模と既存コードの状態に依存する。小〜中規模のアプリケーションであれば3〜6ヶ月が目安だ。Web Formsを多用した大規模システムでは1年以上かかることもある。テストの充実度とWeb Formsの割合が期間を大きく左右する。
Q. WCFサービスはどうすればよいですか？
A. 内部のサービス間通信にはgRPCが最適な代替手段だ。外部向けのAPIにはREST API（ASP.NET Core Web API）を推奨する。既存のSOAPクライアントとの互換性が必要な場合は、CoreWCFで一時的に対応しつつ段階的にgRPCやRESTに移行する戦略がとれる。
現場改善に役立つ関連ツール
GenbaCompassでは、SysDock以外にも現場のDXを支援するツールを提供している。