许多使用微软体系结构的IT经理正在考虑是否应该把他们的开发工具迁移到.NET上。微软承诺使用.NET就能够有更高的效率和程序员也会有更高的产出，同时还能给予VB和C++程序员前所未有的能力和快速的应用程序设计（RAD）工具。微软甚至还引入了一门新的语言——C#，它设计就是用来在.NET Framework上工作的。
尽管充斥着许多关于.NET好处的传闻，但是IT经理的犹豫不决还是可以理解的。.NET是一项新技术，这意味着找到使用.NET成功编写的应用程序是很困难的。而且.NET Framework的学习曲线不是平缓的；VB开发人员有时会发现：转移到VB.NET的困难要比先前任何版本的升级都要大得多。尽管需要付出这些代价，但要下决心完成转移还是有一些正面的观点可以参考的。
1. 标准的集成：XML、SOAP，以及更多的
以往，微软的构件都是建立在COM/DCOM上的，后者是允许跨进程通讯的二进制标准。这个标准本身并没有什么固有的错误，但是它和微软世界以外的标准就没有任何联系了。换句话说，它不能够很容易地同其他软件平台协同工作。
除了和COM缺乏互用性以外，数据是另一个问题。ADO能够允许对数据的轻易访问，但是在把这个数据从一个地方传递到另一个地方的时候就可能会出现问题。ADO
Recordset对象是一个存储数据的二进制结构，但是需要再一次强调的是，这个二进制格式对于微软以外的平台是毫无疑义的。
如果在需要的时候，.NET能够完全遵循标准从而弥补这些缺点。例如，数据会被传递通过XML这样的过程边界，在典型状况下，这个数据有一个到XSD的链接，这样任何客户都可以正确查验这个数据。
SOAP是一个基于XML能同Web服务进行通信的协议。SOAP的集成使得任何客户端都能够通过编程来轻易地访问，而不管客户端正在运行的是否是微软的操作系统。
2. 轻松部署
COM世界里一个最头疼的东西一直就是部署的困难。COM大量使用了Windows注册表来定位机器里的组件。这个概念是好的：已注册的组件只会有一个单一的实例，所有的应用程序都会使用同一个版本。COM承诺新版本能够保持和旧版本的兼容性，但是开发人员可以不受限制而破坏掉这种兼容性，这种情况有时的确会发生。
.NET使用了不同的方法：它根本就不使用注册表。微软推荐的方法是，你让组件（在.NET里叫做assemblies）都成为每个应用程序的本地组件。通过这种方法，用于Foo
应用程序的Assembly X的更改就不会影响到Assembly X的应用程序条了。如果这听起来就像以前同一个DLL会有多个复本散布在计算机里一样，那它的确就是这样的。但是你不会有和应用程序在WindowsSystem32目录里进行查找一样的问题了。
由于.NET并不使用注册表，所以大部分开发工作只需简单地使用复制命令就能做到了。通常没有必要开发安装文件。而且Web应用程序不会锁定组件，所以你就不需要关闭应用程序来升级DLL了。
