MENU

VB.NET（Web Forms/ASPX）を.NET 8へ移行する現実的手順：Upgrade Assistantが通らない理由と段階移行の設計

C#

VB.NET（.NET Framework 4.7）のWeb Forms（ASPX）アプリを.NET 8へ移行したい——結論から言うと「そのまま移行」は難しく、UIはASP.NET Coreで作り替えが必要です。本記事では、なぜ移行ツールで進まないのか、VB→C#変換の現実、段階移行の具体手順を整理します。

目次

VB.NET（.NET Framework 4.7）Webアプリを.NET 8へ移行したいときの結論

.NET 8（ASP.NET Core）へ移行したい理由は、パフォーマンス改善、クラウド/コンテナ対応、最新のライブラリ利用、開発体験の刷新など、現場ではどれも切実です。一方で、VB.NETで作られた.NET Framework 4.7のWebアプリ（MVP構成）を「プロジェクト変換だけ」で.NET 8へ上げるのは、多くのケースで現実的ではありません。特にUIがWeb Forms（ASPX）である時点で、移行は“アップグレード”ではなく“再構築（リプレース）”が主戦略になります。

やりたいこと現実おすすめ方針
VB.NETのまま.NET 8のWebアプリへ移行ツール/テンプレート/周辺が弱く、運用面で不利WebはC#へ寄せ、VBは必要ならライブラリに限定
Web Forms（ASPX）のまま.NET 8へ変換ASP.NET CoreはWeb Forms非対応UIをMVC/Razor Pages/Blazor等で再実装
一気に全面移行（ビッグバン）工期・品質・業務影響リスクが大きい段階移行（共存）で「壊さず置き換える」

なぜ.NET Upgrade Assistantで移行できないのか

「.NET Upgrade Assistantを使ったが移行できない」という相談は非常に多いです。ここで押さえるべきポイントは2つあります。

Upgrade Assistantは“魔法の変換機”ではなく、移行作業の補助ツール

Microsoft Learnのドキュメント上、.NET Upgrade AssistantはC#だけでなくVisual Basic（VB）でも利用でき、ASP.NETなど複数のプロジェクト種別を対象としています。さらに、複雑なWebアプリ向けに「サイドバイサイド（段階）移行」という考え方も説明されています。

ただし重要なのは、Web Forms（ASPX）をそのままASP.NET Coreへ“変換”する機能ではない、という点です。Web FormsはASP.NET Coreがサポートしていないため、UIは別方式で作り直す必要があります。結果として、Upgrade Assistant単体では「UIまで含めた移行完了」になりません。

そもそもUpgrade Assistantは「推奨ツール」が変わっている

2025年末時点のMicrosoft Learnでは、.NET Upgrade Assistantは公式にdeprecated（非推奨）とされ、代替として「GitHub Copilot app modernization」系のエージェント利用が案内されています。既にUpgrade Assistantを触った後でも、この事実は押さえておく価値があります（今後の社内標準や手順書、監査対応に影響します）。

観点押さえるポイント実務への影響
Web FormsASP.NET CoreはWeb Forms非対応ASPXを“移行”ではなく“再実装”として見積もる
ツール選定Upgrade Assistantはdeprecated新規案件は推奨ツールで進める方が将来の説明が楽
進め方段階移行（共存）が安全業務影響を最小化し、リリースを刻める

VBのまま.NET 8のWebアプリに移行できるのか

ここは誤解が生まれやすいポイントです。結論だけ言うと、「VBで.NET 8を動かす」ことと「VBでASP.NET CoreのWebアプリを実務レベルで運用する」ことは別問題です。

  • Upgrade Assistant自体はVBプロジェクトも対象に含めています（少なくとも“分析・補助”の文脈ではVBが前提に入っています）。
  • 一方でASP.NET Coreの世界では、C#中心のテンプレート/サンプル/周辺エコシステムで進む前提になりがちです。VBのテンプレートについては「用意されない」方向の議論が長く続いています。

現場視点でのおすすめはシンプルです。

  • Web（ASP.NET Core）はC#で作る（採用/教育/保守が最も安定しやすい）
  • VBを残すなら「ライブラリ層」に限定（業務ルールや計算などのドメインロジック）

「VBを捨てるかどうか」は感情論になりやすいですが、移行プロジェクトでは“言語”よりも“UI方式（Web Forms）”のほうが難易度を決定づけます。VB→C#が終わっても、Web Forms→ASP.NET Coreは別ゲームだと割り切るほうが、計画と見積もりが現実に寄ります。

VB→C#一括変換ツールはあるか

VB→C#の変換支援として、Visual Studio拡張の「Code Converter (VB – C#)」はよく使われます。Roslynベースで、ソリューション単位の変換にも対応し、ローカルで完結（コードを外部に送らない）という点が実務で扱いやすいです。

変換ツールを使うときの現実的な期待値

「一括変換したら終わり」と考えると失敗します。ツールは強力ですが、“コンパイルが通るC#”まで持っていくには手直しが前提です。特に大規模案件だと、以下のような“VBっぽさ”が残り、設計負債として再燃します。

変換後に起きがち理由現場の対処
Option Strict/暗黙変換の差で警告・バグVBは暗黙変換が入りやすい型を明示、null/DBNull、数値変換を統一
ByRef/Optional/既定値の挙動差言語仕様の違いが表面化メソッド設計を見直し、DTO化や引数オブジェクト化
イベント（Handles/WithEvents）周りの違和感Web Formsのイベントモデルと相性が悪いUI再実装とセットで整理（後述）
プロジェクト参照/名前空間/Resourcesのズレソリューション構造の差・古いcsproj/vbprojSDK-styleへ寄せる前に依存関係を棚卸し

つまり、VB→C#変換は「移行の入り口」です。ここを越えると、次は“Web Formsをどうするか”が本丸になります。

（最重要）ASPX（Web Forms）のUIを.NET 8（ASP.NET Core）にできるか

UIがWeb Forms（ASPX）である場合、Web FormsをそのままASP.NET Core（.NET 8）で動かすことはできません。Microsoftの回答でも、ASP.NET CoreはWeb Formsをサポートしないことが明確に言及されています。

ここで「じゃあ移行できないの？」となりがちですが、正確にはこうです。

  • Web Forms“のまま”は無理
  • Web Forms“から”は移行できる（ただしUIは再実装）

Web FormsのUIを置き換える選択肢

置き換え先の選定は、チームのスキルとシステムの性格で最適解が変わります。Web Formsの「画面イベント中心」「サーバーサイドで状態管理」「コントロールの部品化」に近い思想をどれだけ引き継ぎたいかで選ぶと、判断がぶれにくいです。

置き換え先向いているケースWeb Formsからの移行観点
ASP.NET Core MVC画面/機能が多く、整理しながら移行したいイベント駆動から「HTTP/アクション」思考へ転換が必要
Razor Pagesページ単位で移行しやすい、画面中心のアプリ「ページ＝モデル＋ハンドラ」でWeb Formsに近い感覚がある
Blazor（Server/Was m）コンポーネントでUIを作り、C#中心で寄せたいコントロールツリーに近い発想で移行しやすい場面がある
SPA（React等）＋APIUIを刷新したい、長期的にフロントを資産化したいWeb Formsの考え方から最も離れるが、最終形は強い

「MVPで作っているからMVCにしやすいはず」と期待されがちですが、Web FormsのMVPは“プレゼン層の責務”が散らばっていることも多く、画面数が多いほど“UIの再構成”が発生します。MVPは資産ですが、過信せず、移行前に責務を再定義するのがコツです。

段階移行が現実解になる理由

大規模Web Formsアプリで最も危険なのは、移行期間中に「本番稼働を止める」「大規模な作り替えを一括リリースする」ことです。そこで実務で採られやすいのが、段階移行（Strangler Figパターン）です。Microsoft Learnでも、ASP.NET Framework→ASP.NET Core移行は多くの本番アプリで難しく、段階移行が有効である旨が説明されています。

YARP（リバースプロキシ）で“共存”させて、置き換えを進める

段階移行の典型は「新しいASP.NET Coreアプリを入口にして、未移行のリクエストは既存のASP.NET（.NET Framework）へフォールバックする」方式です。Microsoft Learnのガイドでも、ASP.NET Core側をプロキシとして作り、YARPで既存アプリへ転送する流れが明確に示されています。

この構成にすると、移行の進め方が“業務に優しい”形になります。

  • URL単位・画面単位で置き換えできる
  • 新旧が同じドメインで見える（ユーザー体験を壊しにくい）
  • 本番リリースを小さく刻める（不具合時の切り戻しも容易）

段階移行のロードマップ例

フェーズ目的成果物リスク抑え方
準備移行しやすい形に整地する依存関係棚卸し、テスト観点、ログ整備後で全部詰む「System.Web依存」を見える化
共存基盤新旧が同居できる入口を作るASP.NET Coreプロキシ（YARP）、ルーティング方針URL/認証/セッションが崩れる最初に“共通の横断設計”を作る
小さく移行リスクの低い画面から置換新画面（Razor等）、共通部品二重実装が増える移行対象の選び方をルール化
本丸移行コア業務の置換と最適化認証刷新、セッション整理、データアクセス更新業務影響が出る並行稼働/段階リリース/監視
撤去旧Web Formsを止める旧アプリ退役、運用手順/監査整理残骸が残る“移行完了の定義”を事前に合意

段階共存を成功させる「具体的な実装ポイント」

段階移行は概念だけだと進みません。実装で詰まりやすいポイントを、先に潰しておくことが成功率を上げます。

仮想ディレクトリ構成は新旧で揃える

段階移行では、仮想ディレクトリ（パス）の構成が一致していることが重要とされています。これはルート生成、認可、その他サービスに影響するため、異なる仮想ディレクトリを“うまく吸収する”確実な方法が見つかっていない、という注意書きがあります。最初の設計でパス戦略を決めないと、後で手戻りが大きくなります。

認証・セッションの橋渡しを設計に含める

共存期間中の地雷は「ログイン」「セッション」「権限」です。Microsoft Learnの段階移行向けドキュメントでは、旧アプリとの通信（Remote app setup）や、YARPによるフォールバック、リモート認証・リモートセッションといったトピックが挙げられています。

実務では、次の順で考えると破綻しにくいです。

  1. 共存期間は「認証は旧を正」として、まずは新側は入口/プロキシに徹する
  2. 新画面が増えてきた段階で、認証を中立化（OIDC等）して新旧を寄せる
  3. 最後に旧の認証方式を撤去する

段階移行用の設定例として、ASP.NET Framework側のweb.configにキーを置き、ASP.NET Core側のappsettings.jsonにも同じ値を置く、といった“両者に共通の設定値を持たせる”説明があります。こういった「共存前提の設計」を先に作るのがポイントです。

Upgrade Assistantが案内する「サイドバイサイド（段階）」の考え方を理解する

Upgrade Assistant（または後継の推奨ツール）を使う場合も、発想は同じです。段階移行モードは「.NETプロジェクトを既存の.NET Frameworkプロジェクトの隣に置き、エンドポイントは.NET側で受け、その他は.NET Framework側へ送る」方式として説明されています。ここを理解していると、移行の設計を“ツールの都合”ではなく“アーキテクチャの都合”で組み立てられます。

ロジック層を分離する：MVPを活かして“使い回せる資産”を増やす

Web Forms→ASP.NET Core移行で最初にやるべきは、UIをいきなり書き換えることではありません。最初にやるべきは、「UIに依存しない資産」を最大化することです。

具体的には、次のように分割していきます。

  • ドメイン（業務ルール・計算・状態遷移）
  • アプリケーション（ユースケース：登録、更新、承認、検索）
  • インフラ（DBアクセス、外部API、ファイル、メール）
  • プレゼン（Web Forms、MVC/Razor、Blazorなど）

MVPでPresenter/Modelを持っている場合、すでに「画面とロジックを分ける」土台があります。ここでのポイントは、PresenterがSystem.Web（HttpContext、Session、Request、Response）に触っていないかをチェックし、触っている場合は“境界”を作って追い出すことです。例えば、ユーザー情報や権限は「IUserContext」等のインターフェースに閉じ込め、Web Forms側はそれを実装する、ASP.NET Core側も別実装にする、といったやり方です。

共有ライブラリは「段階移行」前提でターゲットを決める

共存期間があるなら、共有ライブラリは「旧（.NET Framework）でも新（.NET 8）でも動く」形が必要になります。よくある現実解は次のどちらかです。

  • 共存期間はライブラリを.NET Standard 2.0相当に寄せる（両方から参照しやすい）
  • ライブラリをマルチターゲット（net47x + net8.0）にして段階的に新APIへ寄せる

どちらも正解になり得ますが、Web Formsアプリでは古い依存（古いNewtonsoft.Json、古いDIコンテナ、古いEFなど）が絡むことが多いので、最初から“理想の最新構成”に飛ぶより、共存しながら確実に置換できる設計のほうが進みます。

Web Forms特有の機能はどう置き換えるか

Web Formsからの移行が難しい理由は、単に画面が多いからではありません。「Web Formsの機能が、ASP.NET Coreでは別の考え方に置き換わる」からです。置換表を先に作ると、見積もりがブレにくくなります。

Web Formsでよく使うものASP.NET Coreでの置き換えの方向性移行の勘所
ViewState依存の状態保持サーバー/クライアント双方で状態を明示管理「状態が必要な理由」を洗い出し、最小化する
サーバーコントロール（GridView等）UIコンポーネント（Blazor/JS）やテンプレートへ“見た目”より“操作”を先に移行設計する
PostBackイベント（Button_Clickなど）Razor PagesのOnPost/MVCアクション/BlazorイベントHTTP境界で「入力→検証→処理→出力」を定義
HttpModule/HttpHandlerMiddleware/Endpoint/Filter横断機能（ログ、認証、例外）は早めに統一
web.config中心の設定appsettings.json＋環境変数＋シークレット管理段階移行では“共有設定”の設計が鍵

「VB→C#は完了、UIはWeb Forms」その次に取るべき実務手順

後日談としてよくあるのが、「VB→C#変換は終わった。けれどUIはASPX（Web Forms）のまま。ここから.NET 8にできるか？」という状況です。ここからは次の二段構えで考えると迷いません。

まずは“できるところ”から.NET 8対応を進める

  • 業務ロジック/サービス層を.NET 8対応（または共存可能な形）へ
  • データアクセスの方針を決める（既存EF6継続/EF Core移行/段階的置換）
  • 共通部品（ログ、例外、設定、バリデーション）を新側へ寄せる

UIはWeb Formsの概念を引きずらず、置換設計に落とす

Web Formsの画面を移行するとき、よくある失敗は「ASPXページを1枚ずつ“同じ形”で再現しようとする」ことです。Web Formsの“イベントライフサイクル”をそのまま再現しようとすると、ASP.NET Core側で不自然な設計になり、保守性が落ちます。

おすすめは逆です。

  • 画面ごとに「入力モデル」「出力モデル」を定義する
  • Presenter/コードビハインドがやっていた仕事を、ユースケース（サービス）へ寄せる
  • UIは“薄く”し、表示と入力制御に集中させる

すぐに全面移行が難しいなら「共存運用」を前提にする

大規模案件では「移行完了まで2〜3年」になることも珍しくありません。その場合、現実解は既存Web Formsを維持しつつ、.NET 8側で新機能を作って段階共存です。

Microsoft Learnのガイドでも、ASP.NET Core側でプロキシを作り、YARPで旧アプリへフォールバックする形が示されています。これにより、移行中もユーザーは同じ入口から利用でき、開発側は“新しい実装を積み上げる”ことができます。

共存の切り分けは、次のような設計が分かりやすいです。

  • /legacy/* は旧Web Formsへ
  • /app/*（または/feature/*）は新ASP.NET Coreへ
  • まずは「参照系（検索/一覧/詳細）」から新へ寄せる
  • 次に「更新系（登録/承認）」を移行する

画面の選定基準を明文化すると、社内説明・ベンダー管理・品質保証が一気に楽になります。

「移行するべきか」を判断するための比較表

現実には「.NET 8にしたい」だけでは決められず、工期、予算、人材、運用、監査など複数の制約が絡みます。そこで、意思決定のための比較表を用意しておくと、会議が前に進みます。

選択肢概要メリットデメリット向いている状況
.NET Framework継続（4.8/4.8.1へ）Web Formsを維持して延命UI作り替え不要、短期で安定モダン化は進みにくい短期に大改修できない、まず延命が必要
段階移行（YARP＋新旧共存）入口をCoreにし、少しずつ置換リスク低、リリースを刻める共存期間の複雑性大規模・止められない・段階リリース可能
全面リプレース（ビッグバン）新規に作り直して一括切替最終形が綺麗、負債を断ち切れる失敗時の影響が最大スコープが限定的、強い統制と予算がある

.NET Framework延命も「立派な戦略」になり得る

Web Formsを維持するなら、.NET Framework側を最新の4.8.1へ上げる、という選択肢が現実的です。.NET Framework 4.8.1はWindowsに紐づくサポート方針で、サポートされているWindows上で動かす限りサポートされる、とされています。

「.NET 8へ移行できないから終わり」ではなく、延命しつつ段階移行の準備を整えるのは、失敗しにくいアプローチです。

.NET 8のサポート期限も含めて計画する

移行の意思決定では、LTS/STSのサイクルも無視できません。.NET 8（LTS）のサポート期限は明示されており、移行計画の“終着点”をいつに置くかの材料になります。

移行プロジェクトを成功させるチェックリスト

最後に、現場で効くチェックリストをまとめます。移行は「技術」より「段取り」で失敗します。

  • 画面資産の棚卸し：aspx/ascxの数、共通マスタ/ユーザーコントロール、第三者コントロールの依存
  • System.Web依存の洗い出し：HttpContext/Session/Request/Response、HttpModule/Handler、Global.asax
  • データアクセス方針：EF6の継続/EF Core移行/併用/段階移行
  • 認証・認可：Forms認証、Membership、独自認証、SAML/OIDCの有無
  • 運用要件：オンプレIIS継続か、コンテナ/クラウドへ寄せるか
  • テスト戦略：自動テストの導入範囲、移行中の回帰テストの回し方
  • リリース戦略：段階リリース（YARP共存）にするか、全面切替にするか

このチェックリストを埋めるだけで、「Upgrade Assistantが通らない」理由が技術的に説明でき、かつ“次に何をするべきか”が具体化します。

まとめ：最短ルートは「C#＋ASP.NET CoreでUIを作り替え、段階移行で置換する」

VB.NET（.NET Framework 4.7）のWebアプリを.NET 8へ移行したい場合、Web Forms（ASPX）の存在が最大の分岐点です。Web Formsをそのまま.NET 8へ持ち上げることはできないため、現実的な戦略は次のいずれかになります。

  • 短期：.NET Frameworkを4.8/4.8.1へ上げて延命し、移行準備（分離・テスト・共通化）を進める
  • 中長期：YARPによる共存を作り、Razor Pages/MVC/BlazorなどでUIを置換していく

VB→C#変換ツールは確かに存在し、移行を加速できます。しかし、最終的に効くのは「UI以外を再利用できる構造を作ること」と「共存運用を設計して、置換を積み上げること」です。焦って全面移行に突っ込むより、段階移行で確実に前へ進める計画を立てるのが、最短ルートになります。

C#
C# ASP.NET Core VB.NET .NET 8 Web Forms

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次