社内の基幹業務が .NET Framework で動いていて、大きな不具合もなく回っている。ベンダーからは何年も前から「そろそろ移行を」と言われているが、止まっていないものに相応の費用を出す理由が説明できない。サポートもまだ切れていない。 だから毎年、来期に送られます。
維持を選ぶには、サポート状況の確認が必要です。.NET Framework 4.8.1 のサポートは、インストール先の Windows のライフサイクルに従います。全環境が2031年以降まで使えるわけではなく、OS のバージョンとエディションを特定して期限を確認する必要があります。問題は、期限が来る前に別のところから動けなくなることです。
2026年9月8日、.NET 11 RC1が公開されました。正式版は同年11月の予定です。この節目に、移行を先送りしている業務システムについて「何を根拠に、いつ動くか」を整理しておきます。
期限より先に、周りが離れていく
.NET Framework が止まるわけではありません。止まるのは周辺です。
まず、ライブラリです。依存パッケージが今後も net48 向けの更新を提供するかを、パッケージごとに確認します。落とされると、そのライブラリの新しいバージョンが入らなくなります。困るのは機能ではなくセキュリティ修正です。脆弱性が見つかったとき、修正版が新しいターゲットにしか出なければ、パッケージの置換、移行、補完的な対策などの検討が必要になります。対応期限が短いと、調査や検証の選択肢が狭まります。
次に、実行環境です。クラウドのアプリケーション実行基盤は、新しく作る場合の既定が現行の .NET になっています。「今の環境のまま維持する」ことは可能でも、新しく作る側に合わせた選択肢が減っていくのが実際のところです。
そして、人です。.NET Framework 固有の実装には、対応経験を持つ担当者が必要です。保守を引き受けられる人や会社を確保できるかも確認が必要です。これは技術の問題ではなく調達の問題で、保守先を選べるうちに、対応範囲と見積もりを確認しておきます。
まとめると、判断の軸は「サポートが切れる日」ではなく、「動けなくなる前に、動ける時期を自分で選べるかどうか」です。
.NET 11 で何が変わるのか
移行先として見たとき、.NET 11 のリリース候補版で目立つのは次の3つです。
- ランタイムの非同期対応。 同期的にタスクを返すメソッドについて、ランタイム側の非同期版を JIT でコンパイルする仕組みが入りました。あわせて、アンビエントな状態を使っていない場合に
ExecutionContextのキャプチャを省く最適化などが加わっています - プロセッサ数の上限がなくなった。 コア数の多いマシンをそのまま使えます
- AOT コンパイラの改善。 複数のインターフェイス呼び出しを共有ディスパッチでまとめることなどにより、生成されるネイティブバイナリが速く、小さくなります
業務システムの文脈で効いてくるのは1番目と3番目です。1番目は、同時アクセスが多い社内 Web アプリの応答に効きます。3番目は、起動が速くなることと配布物が小さくなることで、コンテナで動かす場合の立ち上がりに効きます。
ただし正直に書くと、これらは移行を決める理由にはなりにくい性質のものです。速くなるのは嬉しいが、いま困っていないシステムを載せ替える動機としては弱い。移行の判断は前節の「周りが離れていく」側でするべきで、.NET 11 の改善は「どうせ移すならこの世代に」という移行先の選択の話として扱います。候補版へ直ちに本番を移すのではなく、サポート中の LTS、必要機能、OS・ライブラリの互換性、次回更新の予算を比較してください。
「バージョンアップ」ではなく載せ替えになる
ここが見積りの認識がずれるいちばんの原因です。.NET Framework 4.8 から現行の .NET への移行は、プロジェクトのバージョン番号を上げる作業ではありません。土台を差し替える作業です。
触ることになる領域は、おおむね次の5つに分かれます。
| 領域 | 何が起きるか |
|---|---|
| プロジェクト形式 | 旧来の csproj を SDK 形式に書き換える |
| Web スタック | System.Web ベースの実装を ASP.NET Core に置き換える |
| データアクセス | EF6 のバージョンとプロバイダーの互換性を確認。EF Core への移行要否は別途判断 |
| 通信 | WCF のサーバー・クライアントを区別し、対応ライブラリや CoreWCF、API 化を検討 |
| 非対応・変更された API | BinaryFormatter の廃止や追加 AppDomain の作成など、利用している機能単位で確認 |
このうち工数が読みにくいのは下の2つです。WCF で社外システムと繋いでいる場合、相手側の都合が絡むので自社だけでは決められません。BinaryFormatter は、セッションやキャッシュの永続化に使われていると影響範囲が広く、どこで使われているかを洗い出すところから始まります。
逆に言えば、上の3つは作業量こそ多いものの読みやすい部分です。見積りを取るときは、下2つの調査を先に切り出して依頼すると、全体の金額の精度が上がります。いきなり一括で総額を出してもらうと、不確実な部分を見込んだ分だけ高く出ます。
全面・部分・据え置きの3択で考える
一括で全部を移すことだけが選択肢ではありません。実務では次の3つを組み合わせます。
- 全面移行。 システム全体を現行 .NET に載せ替える。規模が小さい、あるいは今後も機能追加を続ける予定があるものはこれが素直です
- 部分移行。 外部との接続部分や、変更が頻繁に入る部分だけを先に切り出して新しい側に置き、残りは当面そのまま動かす。全面移行の予算が一度に取れない場合の現実解です
- 据え置き。 変更がほとんど入らず、外部と繋がっておらず、動く環境ごと固定できるものは、あえて動かさない判断もあります
3番を選ぶ条件は厳しめに置いてください。ネットワーク露出だけでなく、OS・依存パッケージのサポートとパッチ適用、バックアップ、復旧手順を確認します。サポート中の .NET Framework をインターネット接続で使うだけで、修正が届かないとは限りません。逆に閉域でもサポート切れが安全になるわけではありません。
どれを選ぶにせよ、判断に必要なのは現状の棚卸しです。どのライブラリに依存しているか、どれが net48 を落としているか、外部接続はどこか。この情報がないまま「全面か据え置きか」を議論しても結論は出ません。AI を使って移行の作業量そのものを圧縮する進め方はレガシー移行を数年から数週間へで整理していますが、これも棚卸しが前提になる点は変わりません。
モバイルアプリ側で同じ世代交代が起きている話は.NET MAUI が Mono を脱却、技術的負債を一度に返さず継続的に返す考え方は継続的モダナイゼーションで扱っています。
次にやること
今期中に移行を決める必要はありません。決めるべきは、その判断をするための材料をいつ揃えるかです。
具体的には、依存パッケージの一覧を出して、それぞれが現行の .NET に対応しているかを確認するところから始まります。調査に要する時間は構成によって変わります。維持を選ぶ場合も、見直し日と条件を決めて記録します。将来の無故障を保証する調査ではありません。何も調べずに先送りしている状態と、調べたうえで先送りしている状態は、来期の説明のしやすさがまったく違います。
.NET を含む業務システムの移行判断、依存関係の棚卸し、部分移行の設計については、グリームハブの開発・AI・自動化のご相談で承っています。既存システムの構成や外部接続の有無によって取れる進め方が変わるため、お問い合わせから個別にご相談ください。
