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 optimize 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 utilizing 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.

Discrete utility ASP files
While examining the ASP and HTML code, check for nested include files. If your application relies heavily on nested include files, you may have to reverse engineer the dependencies of the routines. Additionally, if the include structure has not been normalized, you may find name and functionality duplication when organizing your application into a coherent global structure.

Ideally, all your utility classes will be contained in separate ASP files (or even better as COM objects). Similarly, global variables should be contained in a single ASP file rather than distributed throughout the application.

Vigilant use of sessioning
Beyond server controls, .NET offers new features for enhancing the scalability of Web applications. One of these features is a distributed sessioning model that makes session data available over multiple application servers in a Web farm. No specific modifications to the code base are required for distributed sessioning, although the mechanics involved require using SQL Server to store the application state. Depending on the quantity and type of state data, application performance could be impacted.

To take advantage of this capability without incurring performance degradation, carefully evaluate your current session implementation—especially the quantity, type, and structure of maintained state information. During the migration, tightly control what goes into sessioning. Combine application affinity techniques and failover modes to limit the required state information.

Structured error handling design
A new structural change brought on by VB.NET is the introduction of the Try, Catch error handling mechanism that is familiar to Java programmers. The On Error and related statements are still supported in VB.NET, but best practices dictate moving to the new, structured error handling mechanism. To take advantage of this new error-handling feature, a detailed understanding of the current and anticipated application error processing for your application will be needed.

It’s time to get started
Having a well-positioned application code base can mean the difference between a successful, seamless migration and a project mired with unforeseen difficulties. Examine your system for .NET portability issues and accepted best practices. With luck or prescience, you will find the presentation tier coded in a single language like JavaScript, and the application tier coded in VB, C#, or C++. Ideally, your presentation tier is well organized with little logic of its own and no embedded SQL; and your application tier encapsulates coded business rules through COM objects. At the database level, in an ideal world, you will find stored procedures invoked by the application with COM.

.NET promises many immediate advancements, and like most Microsoft applications, the new platform will only get better. Check your systems now and prepare for the inevitable call for the new functionality available in .NET. Even if your system does not represent the ideal migration candidate, .NET will most likely offer enough advantages to support any necessary rework. At the very least, the chance to migrate to a new platform offers an opportunity to fix longstanding problems in your application. So seize the moment, dig into the code, and get .NET ready.