Redesigned from the bottom up, .Net has made marked progress in areas such as XML integration, error handling, component processing, and reusable frameworks. The promise for Web development is clear: faster development, less custom coding, and increased stability. Once you've decided to migrate current applications to the new platform, you'll need to determine whether your application is .Net ready. This article will help you figure out your .Net capability. Appropriate languages
The .Net framework relies on a common language runtime (CLR) that promises compatibility with multiple languages. In theory, it would be possible to port a Java-based application to .Net without rewriting the application code in C#, C++, or Visual Basic (VB) by using Java COM or Web services. In practice, however, implementing such a heterogeneous application is usually a complex undertaking. Yet changing languages during the migration will also impact the timeline. A language port will almost undoubtedly require architectural changes. Application logic, which is currently coded in VB, C#, or C++, offers the simplest migration to .Net. While not a simple recompile, rewriting to the .Net framework libraries from VB, C#, or C++ gives the best chance of success over a Java COM or other mixed language implementation. Application tier supported by COM objects
If you have a three-tiered system, your application most likely relies on COM objects to encapsulate application logic. COM objects are supported under the .Net framework. However, due to performance degradation with COM object interoperability under .Net, you might want to consider migrating any COM objects to .Net framework-managed objects. Note that performance enhancements gained with .Net's early binding protocols will increase performance for .Net/COM over your current ASP/COM implementation. At the very least, with a current COM implementation you have the choice of whether to migrate to managed objects immediately, or to leave the COM layer in place for the intermediate term. Stored procedures in place
Strong partitioning at the data tier typically relies on encapsulating data manipulation logic within stored procedures. Microsoft has identified using stored procedures as a best practice and relies on their use to optimise database performance. Additionally, stored procedures enhance maintainability by enabling SQL and table changes to be made without impacting application or presentation code. Migrating to .Net will not require any modifications to existing stored procedures. The application routines to execute and manipulate retrieved data from stored procedures will require a migration to .Net framework ADO.Net library methods or the use of COM objects. If you are already utilising COM objects to encapsulate stored procedure calls, essentially no migration effort beyond COM integration will be required. Clearly separated HTML and ASP
One common shortcut to identify in your application is the use of embedded HTML within ASP routines to render an interface element. This practice inevitably causes downstream maintenance problems because of the difficulty in understanding the flow of the embedded HTML and the structure of the rendered code. .Net enforces good programming practice by disallowing these HTML-rendering routines. Instead, custom Web controls are used to encapsulate complex HTML, exposing only the properties and events to the application.