| To upgrade the existing application to .NET, the developer must carefully examine the application and its architecture, components , and business requirements to determine a migration strategy. The migration must be carried out keeping in mind that the existing application should be able to take advantage of the new technology. This section discusses selecting an application for migration and, once an application is selected, the right approach to carry out its migration. It introduces the horizontal and vertical approaches to migration. Selecting an Application for Migration A Web-based application with a simple architecture and high responsiveness can be a good candidate for migration. Possibly, some of the existing legacy applications can make use of the new forms of applications, such as Web services, made available through the .NET platform. The following subsections detail the major considerations in choosing an application for migration. APPLICATION REQUIREMENTS FOR SCALABILITY AND PERFORMANCE If the existing application needs to be scalable and performance is key to the success of the application, the developer will want to upgrade or rewrite that application for the .NET Framework. The .NET Framework provides significant changes that can be reflected in terms of scalability and performance for most applications. APPLICATION ARCHITECTURE The overall application architecture will play a large part in determining whether and how to migrate an application. Thin-client server architecture is seen commonly across Web applications. This is the thin client, written using ASP, followed by some form of middle tier consisting of multiple layers of business logic, and a data access layer connected to a data store. These applications need to be performance driven and scalable to support hundreds or thousands of users simultaneously across the Internet or intranets . This is the type of application we will be looking at for migration to the .NET Framework because of easy mapping to .NET technologies. The user interface, which generally includes HTML elements written in ASP pages, can be easily converted to ASP.NET with some effort. Middle-tier components written in Visual Basic 6.0 can be upgraded using the Visual Basic .NET upgrade tool. The data access components can be converted to ADO.NET and any third-party components can be accessed through the COM interop layer. For such applications or even multitiered applications, deciding which tier should be migrated first or if the entire application should be rewritten depends on the migration approach chosen . This is discussed in detail in the following section. NATURE OF CODE An application containing ASP pages with large amount of server-side code written from the top down is more difficult to migrate than an application containing modular code. Due to the object-oriented approach of .NET and strong typing associated with the .NET languages, existing applications conforming to these standards are easier to migrate. If the application follows object-oriented approach, changes in one part of the application made during migration are less likely to affect any other part of the application or break the application. Also, it is evident that applications with a larger code base will take longer to migrate. Hence, when starting out on migration, it is advisable to pick smaller applications. This will allow the developer to become familiar with the new constructs and syntax changes offered by the technology. Selecting an Approach for Migration After an application is selected for migration based on the preceding guidelines, the developer must decide the best way to approach migration. In this section, we introduce the horizontal and vertical migration approaches: -
Horizontal approach involves migrating an entire tier out of an n -tier application. -
Vertical approach involves isolating and replacing a certain functionality running through all n -tiers of the application. HORIZONTAL APPROACH In the horizontal approach to migration, the developer can migrate an entire tier of the existing multitiered application without changing other tiers. This approach can be used to migrate an entire application tier by tier; it allows the user to take advantage of the features in .NET specific to that tier. The initial step in a horizontal migration is to decide which tier to migrate first. To replace the Web tier, you replace ASP code with code developed using ASP.NET. You may also externally expose much of your middle-tier functionality with .NET Web services. Ideally, the Web tier can be replaced with few or no changes to the middle tier. To replace the middle tier, migrate the existing COM component such that it has little or no effect on the Web tier. VERTICAL APPROACH In the vertical approach to migration, the developer migrates a portion of the existing application running through all n tiers. This involves isolating a part of the application that has minimal interaction with rest of the application. This will include the Web tier as well as COM components. In a traditional ASP application using COM, this could be some functionality that runs independently across the application including the presentation, business, and database tiers. The rest of the application would remain as it was before. This is possible because ASP and ASP.NET can reside side by side within an application. Vertical migration strategy is the best if the application offers good isolation of functionality within the application. Parts of the application that share little or no information with rest of the application can be picked up and replaced. In a typical Windows DNA-based application, ASP pages interact with a COM component, which in turn may call additional COM components before eventually accessing the database. Analyzing the application for such code paths may reveal parts of the application that have minimal interaction with rest of the application. While using the vertical migration, COM components can be migrated using the interoperability feature. Interoperability is covered is detail in Chapter 10. Some issues in vertical migration can arise if there is heavy use of Session or Application objects in the existing application. These objects are not shared across the two technologies, and hence appropriate steps must be taken to avoid their use or replace them wisely. | 
