【保存版】.NET Upgrade Planner入手不可の理由と代替：.NET Upgrade Assistantで安全に移行する完全ガイド（.NET 8 LTS対応）

.NET アプリの長期運用では「どのツールで、どこまで自動化できるか」を早期に見極めることが成功のカギです。かつて移行前診断に使われた「.NET Upgrade Planner」は現在入手できません。本記事では、なぜダウンロードできないのか、正しい代替ツールは何か、そして実務で使える移行手順・チェックリスト・よくある落とし穴まで、WordPressにそのまま貼って運用できる形式で徹底解説します。

.NET Upgrade Planner が入手できない理由と正しい結論

まず結論です。

Upgrade Planner は公開終了しています。以前案内されていた「apisof.net/upgrade-planner」（ブラウザに直接入力）へアクセスしても、ダウンロードはできません。
Microsoft の移行支援は .NET Upgrade Assistant に一本化されました。Planner を合法的に入手する方法はありませんが、Planner の機能（移行前診断）自体は Upgrade Assistant に統合されています。

したがって、これから .NET Framework／古い .NET Core から現行 .NET（LTS は .NET 8）へ移行する場合は、Upgrade Assistant 一択です。

.NET Upgrade Assistant の導入：CLI と Visual Studio どちらでもOK

CLI（グローバルツール）で導入

サーバーやCIでも同じコマンドが使えるため、まずはCLI導入をおすすめします。

dotnet tool install -g upgrade-assistant
upgrade-assistant --version

更新は次のとおりです。

dotnet tool update -g upgrade-assistant

代表的なコマンド：

# 事前診断（Planner 相当）
upgrade-assistant analyze <ソリューションまたはcsprojのパス>

# 対話的アップグレードの開始

upgrade-assistant upgrade <ソリューションまたはcsprojのパス>

Visual Studio 拡張機能で導入

Windows のデスクトップ開発者なら、Visual Studio からも同じワークフローで利用できます。

Visual Studio 2022 以降を開く
[拡張機能] → [拡張機能を管理]で「.NET Upgrade Assistant」を検索・インストール
ソリューション/プロジェクトを右クリック → [Upgrade]（または [Upgrade Assistant]）を実行

CLI/VS のどちらから開始しても、Analyze → Upgradeの二段構えは共通です。

Upgrade Assistant と旧 Planner の違い（用途早見表）

項目	.NET Upgrade Planner	.NET Upgrade Assistant（後継）
配布状況	公開終了・入手不可	公式継続配布（CLI/VS拡張）
主機能	移行前診断（API互換性・影響度）	診断＋半自動アップグレード（プロジェクト形式変換、パッケージ置換、コード修正テンプレ）
対象	.NET Framework/古い .NET Core	.NET Framework/古い .NET Core → 最新 .NET（LTS 推奨）
運用場所	ローカル中心	ローカル＋CI/CD（CLIが使える環境全般）
学習コスト	低	手順は対話式で学習コスト低だが、機能は広い

最短コース：Analyze（診断）→ Upgrade（移行）の実行イメージ

1) Analyze（移行前診断）

まずは影響範囲を数分で可視化します。Planner の役割はここで完全代替されます。

upgrade-assistant analyze .\YourSolution.sln --format json --output .\ua-analyze

API互換性レポート：非推奨API、代替候補、Platform依存APIを一覧化
NuGet 依存関係：置換候補、メジャー更新の有無
プロジェクト構造：SDKスタイル変換可否、複数ターゲットの推奨など

CIで JSON をアーティファクト化しておくと、レビュー観点の共有が容易です。

2) Upgrade（対話的アップグレード）

upgrade-assistant upgrade .\YourSolution.sln

対話に従って、以下の順で適用されます。

バックアップ作成（ソリューション単位）
プロジェクトのSDKスタイル化（旧 csproj → SDK スタイル）
ターゲットフレームワーク更新（例：net48 → net8.0 / net8.0-windows）
NuGet パッケージ置換（互換パッケージ、自動移行テンプレ適用）
コード修正（典型パターンの機械的置換・スタブ追加）
ビルド/テスト実行（フェーズごとに検証）

シナリオ別・現実的アプローチ

ASP.NET MVC 5 → ASP.NET Core

System.Web 依存の分離：コントローラ内部の HttpContext.Current 依存を IHttpContextAccessor に置換。
グローバル初期化：Global.asax のルーティング/DI 設定は Program.cs と app.MapControllers() へ移設。
認証/認可：旧 Forms 認証は Cookies または OpenID Connect へ移行。
前方互換のルート：初期は MVC 5 互換のルーティングに寄せ、段階的にエンドポイントルーティングへ。

最初のコミットでは「コンパイルを通す」ことを最優先にし、動作差分は小さく切って Pull Request を積み上げるのが定石です。

ASP.NET Web Forms

Web Forms は ASP.NET Core に直接移行できません。現実的には次の選択肢になります。

短期：.NET Framework のまま維持管理（セキュリティ/OS 対応を優先）。
中期：新規画面から ASP.NET Core（Razor Pages/Blazor）で再構築し、旧サイトはリバースプロキシで並行運用。
長期：全面再構築。リプレース中も運用可能な 並走リリース戦略を採用。

WPF/Windows Forms（デスクトップ）

ターゲットは net8.0-windows に設定。UseWPF/UseWindowsForms を csproj に明示。
System.Drawing.Common はクロスプラットフォームで非推奨。Windows 限定なら利用可ですが、将来性を考慮し代替（WIC/SkiaSharp 等）へ。
高DPI対応、AppContext スイッチの見直し、ClickOnce/Installer の再発行を計画に入れる。

クラスライブラリ/コンソール

まず 複数ターゲット（例：net48;net8.0）でビルドを通し、互換 API の差分を可視化。
パッケージは PackageReference へ統一。古い packages.config は UA に任せて変換。

移行前に必ずやる準備チェックリスト

チェック項目	目的	実施コマンド/根拠
Git で現状を確定（タグ/ブランチ切り）	巻き戻し容易性の確保	`git tag before-upgrade`
SDK/VS のバージョン固定	ビルド再現性	`global.json` で SDK 固定
CI で `upgrade-assistant analyze` を一度流す	影響面を共有・見積もり	JSON 出力を成果物化
NuGet のソースを見直す	社内ミラー/認証の影響排除	NuGet.Config の整理
テストの整備	機能差分の検出	xUnit/ MSTest を最新化

よくあるビルド・実行エラーと対処

症状	原因	対処
`The type or namespace name 'System.Web' could not be found`	ASP.NET Core では `System.Web` を使用しない	依存の分離・削除。HTTP 周りは `Microsoft.AspNetCore.*` に移行
`packages.config` が残っている	SDK スタイル化が未完了	UA で `PackageReference` へ変換、古いファイルを削除
`FileNotFoundException: System.Configuration`	.NET Core では構成 API が分割	`Microsoft.Extensions.Configuration` 系へ移行、appsettings.json へ
GDI+ 関連の差異	`System.Drawing.Common` のサポート方針変更	Windows 専用に割り切るか、描画ライブラリを差し替え
WCF サーバー側が動かない	ASP.NET Core に WCF サーバー機能は非搭載	移行方針の再検討（gRPC/REST へ）

NuGet パッケージの更新戦略

脆弱性と更新の可視化：dotnet list package --outdated や --vulnerable で棚卸し。
段階更新：メジャー更新は 1パッケージずつ。破壊的変更のリリースノートを確認。
組織ポリシー：私設フィードを使う場合は UA 実行環境の NuGet.Config を事前同期。

プロジェクト変換の要点（SDK スタイル／マルチターゲット）

UA は旧来 csproj を SDK スタイルへ自動変換します。変換後の最小構成例：

&lt;Project Sdk="Microsoft.NET.Sdk"&gt;
  &lt;PropertyGroup&gt;
    &lt;TargetFrameworks&gt;net48;net8.0&lt;/TargetFrameworks&gt;
    &lt;GenerateAssemblyInfo&gt;false&lt;/GenerateAssemblyInfo&gt;
  &lt;/PropertyGroup&gt;
  &lt;ItemGroup&gt;
    &lt;PackageReference Include="Newtonsoft.Json" Version="13.*" /&gt;
  &lt;/ItemGroup&gt;
&lt;/Project&gt;

複数ターゲットを一時的に併用することで、差分ビルドと段階移行が可能になります。

ASP.NET（Core）への移行で押さえるべき設計ポイント

Program.cs：最小ホスト（Minimal Hosting）で builder.Services（DI）と app.*（ミドルウェア/ルート）を整理。
構成：appsettings.json＋環境別（appsettings.Production.json）。シークレットはキーバリューストアへ。
ログ：Microsoft.Extensions.Logging で統一。
静的ファイル/圧縮/CORS：ミドルウェアで明示的に構成。

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();
var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Home/Error");
app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();

app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

CI/CD への組み込み例（YAML 断片）

CLI で完結する UA は、既存のパイプラインに容易に組み込めます。

# 擬似コード（プラットフォーム非依存のイメージ）
steps:
- script: dotnet tool update -g upgrade-assistant
  displayName: Install/Update Upgrade Assistant
- script: upgrade-assistant analyze ./YourSolution.sln --format json --output ./ua-report
  displayName: Analyze
- publish: ./ua-report
  artifact: upgrade-analysis

現場で効く「差分最小化」テクニック

Pull Request を細かく刻む：プロジェクト単位→パッケージ更新→API置換→設定移行の順で分割。
Feature Flags：新旧実装を環境変数/構成で切り替え、段階リリース。
契約テスト：外部システムとつながる箇所は、移行前に HTTP/メッセージの契約を固定化。

移行の「費用感」をつかむ：見積もりクイックガイド

観点	低（1〜2週）	中（1〜2か月）	高（3か月〜）
プロジェクト規模	< 5 プロジェクト	5〜30 プロジェクト	> 30 プロジェクト
UI 技術	コンソール/ライブラリ	MVC/WPF/WinForms	Web Forms/レガシーWCF
外部依存	NuGet のみ	社内SDK/COM 参照あり	商用コンポーネント多用

まずは upgrade-assistant analyze の JSON を読み、「手で直す必要がある箇所」だけを見積もり対象にするのがコツです。

FAQ（よくある質問）

Q. apisof.net/upgrade-planner にアクセスしてもダウンロードできません。

A. そのツールは公開終了です。正統な後継である .NET Upgrade Assistant を使用してください。Planner が担っていた「移行前診断」は upgrade-assistant analyze に統合されています。

Q. Upgrade Assistant は安全ですか？

A. 既定でバックアップを作成し、フェーズごとにコミット可能です。Git ブランチ上で実行し、CI でレポートも残しましょう。

Q. どの .NET をターゲットにすべき？

A. 基本は .NET の最新 LTS（現時点では .NET 8）を推奨。短期サポート（STS）は新機能検証用に限定します。

Q. try-convert は必要？

A. 旧来のプロジェクト形式変換ツールですが、UA が自動で行うため個別に使う必要はありません。

具体的な運用フロー（テンプレート）

ブランチ作成（例：feature/ua-migration）
upgrade-assistant analyze の JSON をレビュー → 作業単位を WBS 化
プロジェクト単位で upgrade-assistant upgrade を実行
テストを通し、アプリごとの最小差分でリリース
監視/ログを注視しながら段階ロールアウト

「コード差分を最小化する」ための置換レシピ集

旧API/仕組み	新API/仕組み（例）	備考
`HttpContext.Current`	`IHttpContextAccessor`	DI から参照。静的依存を排除
`ConfigurationManager.AppSettings`	`IConfiguration["Key"]`	JSON＋環境変数で管理
Global.asax	`Program.cs`（Minimal Hosting）	ルーティング/ミドルウェアを構成
Web.config	`appsettings.json`	機密は秘密ストアへ
Forms 認証	Cookie 認証 or OIDC	近代的なID基盤へ寄せる

品質確保：テスト・監視・パフォーマンス

単体テスト：移行前の挙動を固定する Golden Master テストが有効。
統合テスト：Web アプリは TestServer を活用し、エンドポイントを契約テスト化。
監視/ログ：移行後はログ構造が変わるため、可観測性のダッシュボードを先に整備。
パフォーマンス：Kestrel/GC/スレッドプールの既定が改善。ボトルネックは I/O と DB に移りがち。

まとめ：Planner 不要、Assistant で完結

もう「Upgrade Planner をどこで手に入れるのか」を探す必要はありません。.NET Upgrade Assistant が診断から自動変換までを一貫提供し、CLI と Visual Studio のいずれからでも同じ体験で運用できます。本記事の手順とチェックリストをそのまま実行すれば、現場でも「まず壊さない」「段階的に進める」移行が可能です。今すぐ開発環境に UA を導入し、analyze から着手しましょう。

付録：コマンド早見表

目的	コマンド	メモ
インストール	`dotnet tool install -g upgrade-assistant`	初回導入
更新	`dotnet tool update -g upgrade-assistant`	常に最新版を使用
診断	`upgrade-assistant analyze <path>`	Planner 相当
移行	`upgrade-assistant upgrade <path>`	対話的に実行

この記事を書いた人

佐藤健司

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

【保存版】.NET Upgrade Planner入手不可の理由と代替：.NET Upgrade Assistantで安全に移行する完全ガイド（.NET 8 LTS対応）

.NET Upgrade Planner が入手できない理由と正しい結論

.NET Upgrade Assistant の導入：CLI と Visual Studio どちらでもOK

CLI（グローバルツール）で導入

Visual Studio 拡張機能で導入

Upgrade Assistant と旧 Planner の違い（用途早見表）

最短コース：Analyze（診断）→ Upgrade（移行）の実行イメージ

1) Analyze（移行前診断）

2) Upgrade（対話的アップグレード）

シナリオ別・現実的アプローチ

ASP.NET MVC 5 → ASP.NET Core

ASP.NET Web Forms

WPF/Windows Forms（デスクトップ）

クラスライブラリ/コンソール

移行前に必ずやる準備チェックリスト

よくあるビルド・実行エラーと対処

NuGet パッケージの更新戦略

プロジェクト変換の要点（SDK スタイル／マルチターゲット）

ASP.NET（Core）への移行で押さえるべき設計ポイント

CI/CD への組み込み例（YAML 断片）

現場で効く「差分最小化」テクニック

移行の「費用感」をつかむ：見積もりクイックガイド

FAQ（よくある質問）

Q. apisof.net/upgrade-planner にアクセスしてもダウンロードできません。

Q. Upgrade Assistant は安全ですか？

Q. どの .NET をターゲットにすべき？

Q. try-convert は必要？

具体的な運用フロー（テンプレート）

「コード差分を最小化する」ための置換レシピ集

品質確保：テスト・監視・パフォーマンス

まとめ：Planner 不要、Assistant で完結

付録：コマンド早見表

この記事を書いた人

コメント

コメントするコメントをキャンセル

【保存版】.NET Upgrade Planner入手不可の理由と代替：.NET Upgrade Assistantで安全に移行する完全ガイド（.NET 8 LTS対応）

.NET Upgrade Planner が入手できない理由と正しい結論

.NET Upgrade Assistant の導入：CLI と Visual Studio どちらでもOK

CLI（グローバルツール）で導入

Visual Studio 拡張機能で導入

Upgrade Assistant と旧 Planner の違い（用途早見表）

最短コース：Analyze（診断）→ Upgrade（移行）の実行イメージ

1) Analyze（移行前診断）

2) Upgrade（対話的アップグレード）

シナリオ別・現実的アプローチ

ASP.NET MVC 5 → ASP.NET Core

ASP.NET Web Forms

WPF/Windows Forms（デスクトップ）

クラスライブラリ/コンソール

移行前に必ずやる準備チェックリスト

よくあるビルド・実行エラーと対処

NuGet パッケージの更新戦略

プロジェクト変換の要点（SDK スタイル／マルチターゲット）

ASP.NET（Core）への移行で押さえるべき設計ポイント

CI/CD への組み込み例（YAML 断片）

現場で効く「差分最小化」テクニック

移行の「費用感」をつかむ：見積もりクイックガイド

FAQ（よくある質問）

Q. apisof.net/upgrade-planner にアクセスしてもダウンロードできません。

Q. Upgrade Assistant は安全ですか？

Q. どの .NET をターゲットにすべき？

Q. try-convert は必要？

具体的な運用フロー（テンプレート）

「コード差分を最小化する」ための置換レシピ集

品質確保：テスト・監視・パフォーマンス

まとめ：Planner 不要、Assistant で完結

付録：コマンド早見表

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

.NET Upgrade Planner が入手できない理由と正しい結論

.NET Upgrade Assistant の導入：CLI と Visual Studio どちらでもOK

Upgrade Assistant と旧 Planner の違い（用途早見表）

Q. Upgrade Assistant は安全ですか？

コメントするコメントをキャンセル