Wednesday, May 11, 2011

Process map for upgrading from Classic ASP to ASP.Net

When Microsoft published ASP.Net they made a very large architecture change from their old product of Classic ASP.

Unfortunately when they made this change, they didn't provide a very good upgrade path from the old code to the new, so many programmers still support Classic ASP pages as upgrading them can be very time consuming without a lot of return on investment.

There is no silver bullet for upgrading Classic ASP pages, but I've come up with a standard method that I follow when I have to upgrade pages that seems to work well.

Process map for upgrading from Classic ASP to ASP.Net

1 - Upgrade the majority of your SQL queries to stored procedures

Having your SQL queries as simple calls to stored procedures makes your upgrade easier because when you are trying to debug problems during the transition phase you can rule out syntax problems with your queries.
It also helps if you are trying to migrate from include files to business logic libraries.

This is also something you can do while your Classic ASP site is running, so you can go through the testing and debugging phase with the existing site and rule out any problems that may come about after converting to stored procedures.

2 - Turn your page headers, navigation and footers into a master page

If you have common page headers, tabs along the top, links on the side, copyright links on the bottom, style sheets, javascript libraries or any other common elements that are used across all of your ASP pages, set up a master page to handle as much of it as you can.

3 - Create a base page class

A lot of ASP pages will start out with validation for a user login, initialization of session variables, and loading some database values into memory for later use.
You can create separate business object class libraries to handle all of this, but it helps if you create a simple base page class for all of your .aspx pages to inherit from.
That way you can have your base page's "Page_Load" routine handle any initialization you would normally have to do, as well as declare any variables that will be used across your codebehind page.

4 - Turn include files with HTML output into user controls

If you use include files to spit out large chunks of HTML either through code breaks <% or calls to response.write, create a user control (.ascx file) so that you can have the same functionality through your .aspx page

5 - Turn include files with functions into classes

If you have include files that you use across your application to make database calls or crunch some code, the best place for those is in class files.
If you have common routines that are just used for parsing inputs or just generic functionality, you can create shared classes.
Otherwise you can create specific classes to handle each section of your application.

6 - Turn page functions into functions in your codebehind

If you have functions that you use for crunching code for your .asp page, you should be able to convert them easily to functions in your codebehind for .aspx page.
If it is a function mostly used for outputting HTML to the page, it may not be worth converting.

7 - Grab the HTML from your browser

Load up your current Classic ASP page in the browser, view source and grab the HTML as it is presented.
Paste that into the content placeholder in your .aspx page, cut out the common areas covered by your master page and you have a pretty good starting point.
From there you can paste in your user controls where necessary, and start adding data grids, drop down lists or other server controls that you can bind from your codebehind.

8 - Rewrite the rest

Unfortunately since Classic ASP and ASP.Net are such different animals, you're pretty much guaranteed to lose a lot of code that can't really be migrated very well.
In most cases once you've done all the previous steps it's time to just throw out whatever code hasn't been migrated of the page and put all the pieces together in .Net.