Я бы посоветовал вам сделать свой порт поэтапно, чтобы облегчить переход. Первым этапом будет перенос с рабочего стола VB6 на рабочий стол .NET (формы win).
Затем на втором этапе, если это все еще необходимо, вы перемещаете весь или часть рабочего стола .NET в графический интерфейс ASP.NET.
Переход от VB6 к .NET сам по себе довольно большой для команды, независимо от выбора графического интерфейса. Поэтапный подход позволит вашей команде разобраться с .NET в стиле приложения, более схожем с текущим приложением.
Поэтому ваша цель разделить бизнес-логику на библиотеки многократного использования важна для этого поэтапного подхода к работе. Если вы воспользуетесь этим подходом, у вас будет гораздо больше гибкости в отношении используемого типа (или типов) графического интерфейса.
Например, у вас могут быть все более простые экраны, представленные на веб-сайте ASP.NET, с вспомогательным приложением WindowsForms, содержащим более сложные экраны, которые пользователи могут загружать по мере необходимости. Важно то, что оба из них будут использовать одни и те же библиотеки бизнес-логики, в основном это просто разные интерфейсы для одного и того же приложения.
ASP.NET (или веб-разработка в целом) требует совершенно другого мышления разработчика при работе с состоянием, кросс-браузер, html / css и т. Д.
Недавно я работал над портом / переносом большого настольного приложения Delphi в .NET. Цель состояла в том, чтобы перейти на ASP.NET, однако это полностью упало, потому что существующая команда имела ограниченный опыт веб-разработки и пыталась просто повторно внедрить приложение dektop с использованием ASP.NET. Я бы сказал, что это гораздо больший риск по сравнению с повторным созданием экранов в Windows Forms, по крайней мере конечный результат будет пригодным для использования и предоставит конечным пользователям некоторую ценность.
Хотя Ajax и jQuery значительно улучшили богатство веб-интерфейсов, похоже, что в вашем существующем приложении есть такие области, как представление данных в виде электронных таблиц, которые было бы проще эффективно реализовать в настольном приложении.
Таким образом, «идеальным» является перемещение бизнес-логики и правил в .NET таким образом, чтобы затем можно было просто «подключить» пользовательский интерфейс на более позднем этапе. Это может быть намного легче сказать, чем сделать, но это цель, к которой я обычно стремлюсь.