经验表明，将用户界面（UI）从ASP迁移到ASP.NET，性能将提升50~80%。之所以得到这样的结果，一半的原因是对于大多数良好设计的应用程序来说，惟一未进行原生编译的就是UI。业务和数据层组件已经是编译好的DLL，UI通过一个COM接口来调用这些DLL。由于.NET框架提供了与现有COM对象不错的互操作性，所以较合理的做法就是只将基于ASP的UI层移植到ASP.NET中。
但除了编译和COM互操作性的好处之外，这样做还有另外几个优点:
ASP.NET UI模型
如果开发者以前曾综合运用Visual Notepad和Visual Interdev来进行编辑，在接触了ASP.NET的界面后，很快就会被ASP.NET出色的UI构建模型所吸引。微软通过实现一个新的网页和控制模型，并模拟VB6的开发思维模式，从而显著缩短了UI开发时间。网页模型模拟了Windows消息传递模型，并将其分解成Web客户端和Web服务器两个部分。更重要的是，ASP.NET服务器控件为开发者赋予了VB6风格的窗体功能，能自动管理需要的状态，同时不需要开发者的介入。最终的结果是，开发者用少得多的时间就能开发出可靠得多的UI。
ASP.NET还提供了大量预先写好的控件，并提供了容纳它们的一个框架。这些控件包括TextBox、Calendar、Drop-down List Box、TreeView、TabControl等等。服务器控件提供了与ActiveX控件相似的功能，但它们不要求具有相同级别的客户端配置或权限。注意不是在客户端上执行二进制代码，而是在服务器上执行，并生成HTML输出，以便由客户端浏览器使用。另外，如果浏览器支持，还可生成HTML和JScript的一个组合，允许窗体在客户端上执行，从而尽可能减少Web应用程序所产生的往返行程。
为了将现有的ASP窗体升级到ASP.NET，需要将HTML代码载入一个新的ASP.NET窗体中，然后操纵HTML源代码，将控件变成服务器控件。假如窗体中有大量脚本代码，并利用了Visual Interdev设计器，那么较容易的做法是运行ASP应用程序，然后在浏览器中选择【查看】|【源文件】，剪切并粘贴HTML，从而将基本的窗体载入ASP.NET。
可扩展的UI模型
为了真正发挥出ASP.NET的优势，你不仅要从一个现有的ASP应用程序拷贝HTML代码，还应利用ASP.NET的代码重用能力，方法是将网页元素定义成可重用的控件。利用ASP.NET UI模型的扩展能力，你可对常用功能进行分组，并综合运用新的Page基类、用户控件以及Web服务器控件来实现新的ASP.NET网页，并用它取代原始的ASP网页。例如，公司用户在使用由公司的不同部门提供的ASP应用程序时，要解决的最困难的问题之一就是如何应付形形色色的UI模型。
如果你的公司打算迁移到ASP.NET，我们的第一个建议是将自行设计的菜单和导航系统替换成网页类和用户控件的一个内部ASP.NET实现，或者替换成第三方组件厂商的标准导航实现。
对于第三方导航系统，注意要选择提供了.NET源代码的产品，这样才能建立自己的内部导航标准。通过在所有ASP.NET系统中重用这个实现，你的用户就能获得统一的导航机制。另外，还能显著减少为未来的系统编写的导航代码数量。
UI迁移的其他好处
除了UI开发模型所带来的好处之外，还应全面地利用ASP.NET内建的缓存和会话状态机制。开发者只需少量工作，即可利用ASP.NET输出缓存机制，为用户显著地改进网页加载性能。如果需要缓存单独的对象，或者要对网页缓存机制进行细致的控制，可利用内建的Cache API来进行更加明确的缓存控制。
除非你实现了自己的专用状态管理机制，否则经典ASP内建的会话状态管理不允许应用程序扩展到一台机器的范围之外。虽然我对“会话管理”的建议保持不变——除非绝对需要，否则不要用它——但使会话状态跨越多个前端服务器的机制是内建于ASP.NET中的。你既可使用单独一个状态服务器，由它将一组Web服务器的状态存储到自己的内存中，也可将状态存储到一个公共的SQL Server后端。无论选择哪种机制，都要求在本地Web.Config文件中进行一处简单的更改。根据我在这两种机制上的经验，建议你将状态数据存储到SQL Server中，尽可能增强可用性及可靠性，因为进程外状态服务器并不能带来显著的性能优势。