2002 – 2012ASP.NET WebForms↳ASP.NET CoreとRazor PagesまたはBlazor
ページライフサイクル、ViewState、サーバーコントロールには同等のものがないため、マークアップは実際に書き直すことになります。しかし、その下のビジネスロジックは通常そのまま使えます。この2つを切り離すことが、作業の大半を占めます。
2003 – 2010ASMXおよびWCFサービス↳ASP.NET Core API、gRPC、またはCoreWCF
バインディング、ビヘイビア、SOAPの契約はそのままでは移行できません。呼び出し元が変更できない外部の組織である場合は、CoreWCFで契約を維持したまま、その裏側をすべて移行します。
2007 – 2015Silverlightおよびブラウザプラグインのクライアント↳Webフロントエンド、またはモバイルアプリ
移行先はありません。ランタイムはすべてのブラウザから姿を消しています。まずは、そのアプリケーションが本当に何をする必要があったのかを整理するところから始めます。
2008 – 2019DataSet、EF6、手書きのADO.NET↳EF Core、または必要に応じてDapper
データ層は、単純な移行が高くつくポイントです。クエリ変換、トランザクション、遅延読み込みの挙動はすべて異なり、その違いはコンパイル時ではなく本番環境で表面化します。
2009 – 2016ASP.NET MVC 5およびWeb API 2↳ASP.NET Core MVC
このリストの中で最も機械的に移行できるものです。本当の作業はコントローラーではなく、ホスティング、構成、依存性注入、ミドルウェアパイプラインにあります。
2002 – 現在WinFormsおよびWPF↳最新の.NETデスクトップ、またはスマートフォン向けならMAUI
どちらもモダン.NET上で動作するため、書き直しになることはまれです。障害となるのは、サポートが終了したサードパーティのコントロールスイートとCOM相互運用であり、私たちはまずそこから調べます。
全バージョン.NET Frameworkのクラスライブラリ↳最新の.NET(移行期間中はマルチターゲット)
共有ライブラリこそが、新旧のシステムを並行稼働させる鍵です。まずマルチターゲット化することが、このリストの他のすべてを進める突破口になるのが一般的です。
継続的packages.config、レガシーcsproj、Windows Server上のIIS↳SDKスタイルのプロジェクト、コンテナ、自動で回るCI
地味ですが、これがあるからこそ他の作業を再現可能にできます。移行が完了するずっと前から効果が出るため、最初に取り組むべきことである場合も少なくありません。