As developers in the 1990s, we became accustomed to migrating applications from one version of VB to the next. We expected Microsoft to continually provide new VB releases that addressed feedback from the developer community (also known as "identified bugs"), made VB software developers more productive, and took another step toward "true" object-oriented (OO) programming. While Active Server Pages (and VBScript) provided a foothold into Web development, they also represented a step backward in the path to building OO systems. .NET is the realization of the drive toward full object-oriented development for VB developers - for building both PC and Web-based applications.

However, between that last client/server application in VB and today, most of us spent time writing ASP code, and now find ourselves confronted with the opportunity to migrate ASP (VBScript) applications to ASP.NET using VB.NET. While such a migration may be motivated by important business drivers, knowledge of .NET also represents a career opportunity for any ASP developer. According to the Netcraft Web Server Survey (March 2004), in the past year the number of sites using ASP.NET jumped 224%, surpassing the number using JSP and Java servlets. So, if you want to maintain your competitive edge, start hitting the books on .NET and look for ASP applications that could benefit from a move to .NET.

Looking for Opportunities
Does your CTO have a position on how .NET fits in your overall IT strategy? Maybe there's a policy that new application development will be .NET-based, and the company is laying the foundation (training, hardware and software infrastructure, and more training) to make it succeed. More than likely, however, that's not the case. It's often still up to the individual developer, or small groups of intrepid innovators, to bring about changes that yield better software.

In looking for opportunities to migrate ASP code, consider the time required, risks involved, and the rewards to your organization. In the following matrix, short timeframe projects may yield less "strategic value" per se, but provide an invaluable tactical advantage: they get you into .NET development fast and allow you to demonstrate immediate value while establishing the groundwork for creating more value in subsequent efforts.

The .NET Migration Matrix provides a clear visual guide to the relative positioning of various migration strategies.

Organizations that don't perceive a high strategic value in moving to .NET or who want rapid time to results generally select one of two approaches:

• Test the waters: This approach means migrating an application (or a near stand-alone subsystem) for evaluation purposes. Evaluation metrics include not only typical performance measures, but also measuring the migration project experience (time to complete, unexpected issues, etc.).
• Face lift: This involves the migration of the user interface tier of a system, which often includes general UI enhancements such as better validation, improved user controls, and functionality. These are all laid out according to the way in which the system is actually used.

Organizations that seek more long-term benefits and place a higher strategic value on the migration pursue different approaches:

• Co-existence: Essentially a subset of test the waters, it involves the migration of a discrete area of functionality and is designed to interoperate as part of the existing application. An example would be the migration of a portion of reusable business logic and providing a Web services interface to it.
• Draw the roadmap: This is an investment in re-architecting a system to make the best use of the .NET framework. While some development occurs, the primary objective is to provide a comprehensive and detailed design that will guide subsequent development projects.
• Just do it: Once it has been determined that a system must migrate due to strategic business needs, this approach entails full design, development, and deployment of the system in .NET, .

Evaluating the Complexity of an ASP.NET Migration
Across the various categories of migration, it's important to consider a number of factors that contribute to the complexity of the migration. These include:

• The complexity of the existing code base, including issues caused by numerous developers making changes to the code base over time, and the completeness and accuracy of documentation.
• The overall degree to which a multitiered separation of code exists. (Has business logic been introduced in the presentation layer, for example, through ASP or JavaScript within HTML pages?)
• The degree to which COM objects are used to encapsulate business logic.
• The database structure, and the degree to which data access functions reside in a centralized data tier.

You can estimate the potential complexity of a migration across these factors using the evaluation system shown in Figure 2. By rating how strongly you agree or disagree with each statement, you can quickly make a preliminary assessment of the level of complexity you'll face.

Evaluating the Complexity of Your ASP.NET Migration
Overall scores below 12 suggest a relatively straightforward migration. Scores from 13 to 18 indicate a level of complexity that warrants building in additional time, particularly for code analysis and testing. Scores above 18 point to a high degree of complexity in the migration, requiring a significant amount of redesign.

Deciding on a Migration Path
Based on your migration goals, the category that best fits your migration, the complexity and architecture of your existing system, and your budget and available resources, you can implement one of two distinct migration paths: vertical or horizontal.

In a vertical migration, application code is migrated module by module, completing the migration for all three tiers of one module before moving to the next. As shown in Figure 3, a vertical migration proceeds through Module A's Web pages, business logic components, and database interface before moving to the migration of Module B. A vertical migration is most appropriate when application modules are loosely coupled and when interfacing between different application tiers is a tedious task.

A horizontal approach calls for migrating an application one tier at a time. As shown in Figure 4, a horizontal migration approach proceeds through all of the pages of the user interface tier for each module, followed by the business and data tiers. This strategy is most appropriate when the application's modules are tightly coupled and minimal changes are required to the interfaces between application tiers.

The Migration Lifecycle
Migrating a typical ASP application to ASP.NET generally encompasses four stages:

1. Code analysis: Analyze existing code and create a project-wide migration strategy (including code modification, test plan, checklist-based review, etc.). Determine the migration scope and explicitly list functionality or modules that will be out of scope. Identify functionality that can be replaced with .NET controls.
2. Conversion: Perform the actual migration based on the established strategy (code changes, unit testing, peer review, etc.). If possible, begin concurrent development using a sub team that is focused on developing code that was identified as reusable across namespaces.
3. Refactoring: Perform any applicable code optimization, which is targeted at modularization, design improvement, and performance gain. By having a separate phase devoted to refactoring, you increase the likelihood of leveraging the capabilities .NET can provide.
4. Testing: Conduct functional and nonfunctional testing.

In a horizontal migration methodology, these four stages are iterated for each tier; in a vertical migration, they are completed for every functional module.

Expect to allocate approximately 15-20% of project time to code analysis, 40% to conversion, 10% to re-factoring, and 30-35% to testing.

Migration Tools
Before beginning your application review, create a series of categories with which to classify the current ASP files (as well as COM objects, JavaScript files, and any other code used in the application). Categories include the usual suspects - UI, business logic, and database. For ASP applications, the categories will really be "mostly UI," "some business logic," "a little bit of everything," and "UI utilities." During your application review, note in which category each file belongs and add comments for use during subsequent project planning. You'll find that some files fit into more than one category and that the number of categories may grow. The nature of how most ASP applications were developed means that you'll have to be diligent about seeking opportunities to refactor code.

Another useful tool in migration is a project plan that lists the process steps to be taken with each file. For example, you could use a spreadsheet that lists ASP files in the lefthand column, followed by columns such as "complexity rating," "HTML separation," "ASP class conversion," and so on.

While code-generation tools are becoming increasingly popular for new development, there isn't much in the way of automation available for migrating code to .NET. Microsoft provides a tool, developed by ArtinSoft, which provides some automation. The ASP to ASP.NET Migration Assistant shouldn't be relied upon as the sole means of migration - someone will still need to write (or generate!) code to complete the effort.

Building Your Case for Migration
Using the Migration Matrix and Complexity Evaluator can help you if you intend to conduct a skunk works effort (also known as "what software developers do on nights and weekends") or if you intend to present the business case for migration and get approval to spend daylight hours on the migration project.

If you're building a business case for the migration project, here's some good background information for you to plug into your presentation on the slide called "Benefits of .NET."

• Industry adoption: The adoption of .NET has accelerated in the last year, which is partly due to Microsoft's release of Windows Server 2003. The release included the .NET Framework as an integral part of the Windows 2003 operating system as well as improved .NET-specific development tools such as Visual Studio .NET 2003.
• Interoperability: Because the .NET platform has a high degree of compliance with industry standards for Web services, it effectively promotes interoperability across applications on a variety of platforms, including J2EE.
• Scalability: When traffic increases and the architecture calls for employing multiple servers to facilitate load sharing, ASP.NET maintains session information storage in a separate server or database on either the server side or the client side, depending on security or access requirements.
• Reliability: .NET creates "application domains," which are logical and physical boundaries around each .NET application that isolate it from others, preventing the stability of any one .NET application from affecting that of others. It also incorporates such services as debugging, profiling, security, and memory and exception management.
• Maintainability: .NET promotes the separation of application logic from user interface code, allowing maintenance activities to be more readily performed by developers with relevant skill sets. In addition, because the .NET environment takes over application management functions previously managed by Windows, it simplifies updates. For example, it is unnecessary to bring down a server to make updates because the Windows registry isn't relied upon to manage DLL versions in .NET.

What Are You Waiting For?
The .NET platform provides an object-oriented version of VB that can be used to develop both stand-alone and Web-based applications. Anecdotal and quantitative evidence points to a dramatic increase in the adoption of .NET in corporate IT. Take the initiative to look for an opportunity within your organization to work on a .NET project. Alternatively, get a group of like-minded developers together and start a skunk works effort to migrate a small-to-medium ASP application. Convert a current user (someone as influential as possible) to your cause, and incorporate some of his/her feedback into the new version.

.NET provides individuals and organizations with the same type of opportunities that VB3 did back in the early '90s - a faster way to develop reusable code. The difference is that the opportunities .NET provides are orders of magnitude greater than what we experienced a decade ago. Migrating ASP applications is an excellent way to build your .NET expertise while doing a good deed for your organization.

• Figure 1
• Figure 2
• Figure 3
• Figure 4