Before converting an ASP application to ASP.NET, you must decide whether you are porting the application or rewriting it. Porting the application involves making only the necessary changes to get it to run under ASP.NET. This is the quickest way to move the current ASP application to ASP.NET, but the time and cost saved now might be spent later as you end up rewriting the application anyway to fully take advantage of the .NET architecture. Rewriting the application enables you to get the most out of ASP.NET, but at the expense of having to throw out much of the work previously done for the ASP application.
Advantages of porting include speed of conversion, the opportunity to learn how .NET works before designing an application for it, and the ability to get the most out of your previous development investment.
Disadvantages of porting include less than optimal performance, higher ongoing maintenance costs, and tying at least portions of your application to legacy code.
Advantages of rewriting include optimal performance, objectization of both user interface and back-end code (which will make it reusable in the future), and lower ongoing maintenance costs.
The only real disadvantage of rewriting is that it requires you to throw away the time and costs involved with implementing the current system, even though these will, to some extent, be recovered through lower maintenance costs in the future.
In addition, applications may be partially rewritten if you want to reach a compromise between a minimal port and a complete rewrite. The better the job that was done to separate the code from the user interface in the ASP application, the easier it will be to convert it to an ASP.NET application that best takes advantage of the features of the .NET architecture. Also remember that it is not necessary to port the entire application to ASP.NET to take advantage of the capability to rewrite portions of it in ASP.NET or add new features using ASP.NET.
Let's look at some sample situations to show how the choice between porting and rewriting will be different for every site. We will look at the following scenarios:
Each example will have different optimal choices for rewriting and porting. Time and monetary constraints, along with how well a site is designed and implemented, will lead to different choices for real-world sites.
In our first example, we have a small, low-traffic Web site. Different people have maintained this site at different times. New features have been added without thought to trying to reuse code or to centralize error handling. Occasionally, the site users will get errors, but because these errors are inconsistent and reloading the page will often result in the correct output, they are seldom tracked down and fixed.
Because in this example the site is poorly coded and error prone, it should be easy to decide that a move to ASP.NET requires a complete rewrite of the site. If a site is too poorly coded, it might even take less time to rewrite all the code than to try to port the current code. Once the site is rewritten, it should be less error prone and require less maintenance provided that the rewrite was well designed. Rewriting the code of the site does not mean that the site needs to be totally redesigned, because it is the code that needs to be rewritten. The visual aspects of the site do not need to be changed, though this can be an opportunity to do a total redesign or to add new features if you thought the site needed an update. Following is a list of things to consider when rewriting the application:
Large Company Intranet
For our second example, we have a large company intranet. In this case, the site was well designed using COM objects to encapsulate all the business logic. Because a lot of money was spent developing the site and the COM objects, saving as much of this investment as possible is important.
This example is a good argument for porting. A total rewrite would cause you to lose a large portion of the time spent doing a good job on the current implementation while providing minimal gain. The ASP code can be ported, and the COM objects can continue to be used. The COM objects can be rewritten to .NET classes at a later date if significant changes to the business logic are required or if it is determined that any performance gain is significant enough to make it worthwhile. Following is a list of considerations when porting an ASP application:
High-Traffic E-Commerce Site
For our last example, let's look at a high-traffic e-commerce site. This site has been reasonably maintained and documented. It uses COM objects for the business logic, much like the previous example. The main difference from the large company intranet is that this site can't be down for even a minute because the company depends on the revenue generated by this site. Also, the site is constantly being updated with new features to differentiate it from other e-commerce sites, and this continual addition of new features can't be stopped for the length of time necessary to do a complete port of the application.
In this situation, the best answer would be to continue running the current application under ASP while adding new features with ASP.NET. As time allows, different segments of the application can be ported or rewritten one at a time. This method enables you to get started using ASP.NET and take advantage of its new features as soon as possible without taking the time to convert your current application. The main thing to be careful of is that Session and Application data is not shared between ASP and ASP.NET. If you are storing data in the Session or Application variables , you might need to develop a custom solution to share this data between ASP and ASP.NET.