Migration Strategies

After deciding to migrate parts or all of an unmanaged application to .NET, you need to choose the appropriate migration strategy. You may need to migrate a part of the application across all tiers, such as presentation, business, middle, or data, or migrate a part of your application across a tier. The two approaches for migration are horizontal and vertical migration approaches.

Horizontal Migration

Horizontal migration allows you to migrate a specific tier of an unmanaged application to .NET without migrating the other tiers. For example, you may choose to migrate the presentation tier of your application from ASP to ASP.NET. By choosing horizontal migration, you can migrate one tier at a time and use the features of .NET Framework that are specific to the tier. For example, to migrate the presentation tier from ASP to ASP.NET, you can use the features that ASP.NET provides to Web applications.

Figure 2-1 shows horizontal migration:

Figure 2-1: Horizontal Migration

Horizontal Migration: A Case Study

An enterprise software development company owns a Bug-Tracking Web application in which the presentation tier is in ASP and the middle tier contains COM components. The application is based on the roles of end users, such as Quality Assurance, Team Leader, Software Developer, or Project Manager. A separate interface exists for each category of end user. An end user can view and update the bug status for a project in the interface. COM components provide data to end users about bugs and form the middle-tier architecture. In addition, the application involves intensive use of session- and application-specific data because the application contains multiple interfaces, such as login, view bug status, update bug status, reports, comments, and automation. The application needs to maintain the identity of the end user across multiple pages and requests.

To replace the presentation tier in the Bug-Tracking application, you need to replace ASP code with ASP .NET code. You also need to replace some of the middle-tier functions that the COM components provide with .NET Web services. The benefits of migrating the presentation tier from ASP to ASP .NET in the Bug-Tracking application are:

• Compiled code: Results in better performance because compilation is always faster than interpretation. ASP code is interpreted while ASP.NET code is compiled. ASP.NET code is complied once and stored in a cache. When a request arrives for the page, the Web server loads the cached copy of the page on the Web browser.

• Web forms: Results in faster development of Web applications and provides server-side event handling. .NET Framework provides the Web Forms package that provides a set of controls along with their properties, methods, and events that you can use to write the logic behind the user interface of Web applications.

• Server-side controls: Facilitates the development of Web applications that target multiple browsers. Server-side controls work in .NET Framework and can work with Web forms. The end user can access the Bug-Tracking application on any browser, such as Internet Explorer, Netscape, or AOL.

• Easier configuration management: Provides an efficient way to define configuration settings for ASP.NET applications. ASP.NET provides the configuration file in eXtended Markup Language (XML) format, which you can read using any XML parser. You can define configuration settings at the time of deployment, and can edit the settings later without stopping the Web server. For example, the Bug-Tracking application uses a new version of a component that the application uses to synchronize the bugs system on the Automation page. In the ASP scenario, you need to deploy the new version of the automation component again, which means that you need to restart the Web server. Alternatively, in ASP.NET, you specify the new version number of the automation component in a configuration file that the application can read while it runs.

• Session state management: Provides improved session state-management features. You can use the SQL database and a Windows service to hold session data. The Bug-Tracking application uses cookies on the Web client to store the session ID of a user session. Consider a situation where the client disables cookies. The Bug-Tracking application will no longer be able to store the session related information of a particular end user that accesses the application. In ASP.NET, you need not use cookies to store the session ID of a session variable.

• Caching: Provides Cache API to store session- and application-specific data and an output cache to store frequently requested pages. The ASP-oriented Bug-Tracking application stores session- and application-specific data in cookies on the client computer. This involves reading and sending data back and forth to the Web server. ASP.NET stores session- and application-specific data in the easily accessible cache. This mechanism is faster and more flexible than the cookie mechanism.

To check whether horizontal migration of the presentation tier from ASP to ASP.NET is feasible, you need to consider the following characteristics of the Web application:

• Web farm configuration: Necessitates that the CLR is present on each Web server on which the application is to be deployed. In a Web farm configuration, you should provide the CLR on each Web server that is part of the Web farm. The Bug-Tracking application does not use a Web farm configuration.

• State management: Makes intensive use of application and session state management. As a result, it is desirable to migrate horizontally to ASP.NET because it provides enhanced state management.

• Complexity of middle-tier components: Requires interoperability calls between the COM environment and the .NET environment. This could result in performance degradation while migrating some of the components of a complex middle tier. You can change middle-tier functions by replacing COM components with Web services, which expose functions to applications regardless of the language, object model, and platform that the applications use.

When migrating the presentation tier from ASP to ASP.NET, you must:

• Deploy CLR on each Web server that will host the Bug-Tracking ASP.NET application.

• Replace the connected data access that ADO provides with the disconnected access that ADO.NET provides. Replace the recordset objects with dataset objects to facilitate disconnected data access.

• Deploy primary interop assemblies that facilitate the interoperability of existing COM components with the managed code in the Bug-Tracking ASP.NET application.

Figure 2-2 shows horizontal migration of the presentation tier in the Bug-Tracking application:

Figure 2-2: Horizontal Migration of the Presentation Tier

Vertical Migration

Vertical migration allows you to migrate a portion of your application through all application tiers. This portion needs minimal interaction with other portions of the application. For example, you can migrate the search functionality of your Web application, including the presentation, business, and data tiers, to .NET. The remaining functionality of the application lies with COM and ASP. After migrating a part of your application vertically, you need to perform some development and testing tasks to ensure that the new and old portions of the application work together and share data.

Figure 2-3 shows vertical migration:

Figure 2-3: Vertical Migration

Vertical Migration: A Case Study

The Bug-Tracking application includes a Search feature that allows users to search comments by other users, specific types and levels of bugs, and the synchronized status of bugs. The Search feature is isolated from other features of the application because this feature provides an interface where the user specifies search text and criteria. The Bug-Tracking application uses ASP for the presentation tier, COM for the business tier, and ADO for the data tier.

The benefits of vertically migrating the Search feature of the Bug-Tracking Application through all tiers, such as presentation, business, and data, are:

• Application isolation: Allows easy vertical migration with little impact on the rest of the application because the Search feature is isolated from other features of the Bug-Tracking application.

• Easy addition of new functions: Allows addition of new functions using .NET Framework in the Search feature of the Bug-Tracing application For example, you can add advanced search, which may include searches based on client feedback, to the Search feature.

• Provision of Re-architecture facilities: Allows you to plan a re-architecture of your application by vertically migrating part of your application to the new architecture. This provides a good checking option for the new design. .NET Framework offers the simpler functions that newer architecture requires. For example, HttpHandlers provides many tasks with an easier programming model for which you might have used Internet Server API (ISAPI) extensions earlier.

If you use the vertical migration approach for the Search feature of the Bug-Tracking application, you must consider the following issues:

• Interaction between ASP and ASP .NET code in a mixed ASP/ASP .NET environment: Requires consideration when using the redirect command from an ASP page to an ASP.NET page. Vertical migration makes it difficult to communicate in a mixed ASP/ASP.NET environment. As you vertically migrate a part of your application to .NET across all tiers, the presentation tier converts from ASP to ASP.NET. If you need the migrated part to communicate with other parts of the application, you have to work in the mixed ASP/ASP.NET environment.

• Session and application state management in a mixed ASP/ASP .NET environment: Prevents the session and application state-management objects from managing state across the two environments. As a result, you need to avoid the use of the session and application state-management intrinsic objects.

• Installation of CLR on each Web server: Requires CLR installed on each Web server that the application is using. You cannot run some parts of the application if CLR is not present on any of the Web servers.

Figure 2-4 shows vertical migration of a part of the Bug-Tracking application through all tiers:

Figure 2-4: Vertical Migration Through all Tiers