私たちは、歴史的な理由と開発のスピードアップのために、WinFormsの対象となったエンタープライズアプリケーションを開発/管理しています。
今、私たちは遅かれ早かれ（遅かれ早かれ）そのアプリケーションはWebベースである必要があると考えています。
「Webへ」の動きについて考える。私たちが考慮しなければならない最も重要なことはどれですか？MVPパレード（またはその他）のようなもので、使用するプラットフォーム/フレームワークの種類を決定します...
WinFormからWebへの移行に関する経験はありますか？世話をするための提案はありますか？
宣言：このシナリオでは、アプリケーションはWebベースであると便利ですが、現実的です。すべてのアプリケーションがWebベースである必要はないことに同意します（これがWinFormsで開発した主な理由です！）。ただし、要件が変更されることがあり、このシナリオでは、そのアプリケーションをSaaSとして提供したいと考えています。
重要なことは、ユーザー インターフェイスを他のすべてのものから完全に分離することです。これが完了したら、アプリケーションを移植するためにアプリケーションを書き直す必要はありません。その上に Web UI を作成するだけです。
私は、モノリシックなWinFormsアプリケーションで同様の状況を経験した会社で働いていました。その経験から、考慮すべき2つのことがあります。
1]すべてのデータアクセスロジック（DAL）を既存のWinFormsUIから切り離します。Web開発を開始する前に、このプロセスを開始できます。
このリファクタリングは、毎週6回のスプリントで行いました。アプリの一部は簡単に変更できました。その他の部分は、WinFormの背後にあるコード内のDAL、インラインSQL、およびUIコードをすべて織り交ぜた完全に地獄のようなスパゲッティコードで構成されていました。
この分離を行うと、2つの異なるUIをサポートするのが簡単になります。
2]ASP.NetMVCとターゲットWebフォームを無視します。WebFormsは、従来のWinForms UIコード（イベント駆動型、コンポーネントベース）の作成経験に近いWebアプリケーションの作成を可能にするように設計されました。
ページのライフサイクルを理解する必要があります。動的に生成されたコントロールには、多くの新規参入者をつまずかせる傾向のある概念的な落とし穴がいくつかありますが、それ以外の場合は、WinForms開発者のチームにWeb作業を行わせる最も簡単な方法です。MVCは現在、Webサークルで非常に人気があり、関心の分離が向上しています（ただし、勤勉で強力な設計リーダーシップがあれば、WebFormsでも同様の結果を得ることができます）が、より高度な知識が必要です。MVCを使用すると、HTTP要求/応答サイクルの金属に近づきます。WebFormsは、その多くを抽象化します。
頑張って頑張ってください！
NESBAWA (すべてが Web アプリである必要はありません)。
ジョンは正しい。ただし、「空のクライアント」アプローチについて聞いたことがありますか? これは、プレーンなブラウザーで Web アプリケーションとしても実行できる .NET WinForms アプリケーションを開発するためのかなり新しいアプローチです。このアプローチにより、必要に応じて WInForms アプリケーションを開発し、それを Web 上に置くことができます。追加の開発や調整は必要ありません。それを行うフレームワークの 1 つがVisual WebGui です。