converting Legacy ASP app to ASP.NET: best approach

Question

I've taken over support of a legacy web app written predominantly in classic ASP. One page has a form for doing a job estimate, and consists of about 2500 lines of javascript and ASP code to achieve a "transparent edit" - i.e., the form is always in edit mode, and changes are instantly updated into the DOM.

There is also a "Print To Word Doc" button that, when clicked, goes to an entirely separate ASP file that produces (supposedly) the same view in HTML sent downloaded to a Word document.

The problem is that we have discovered inconsistencies and bugs in the two versions that are produced. My first response, applying the DRY principle, was This needs to be re-written in ASP.NET with a single code-behind file outputting the view for both the web page and the word document, so that we have one place to maintain the source.

However, upon getting into it, I'm questioning the wisdom of that approach, and I'm soliciting advice.

The problem is that, because of the integration of the view with the editing on the web page, as opposed to simply presentation on the work document, the two functions really do have two different purposes. Also, the ASP code, while ugly and hard to maintain, produces a reasonably nice-looking document. Doing the same thing in ASP.NET, at least using ASP.NET controls like FormView, is proving challenging. (One of the rewrite requirements is that the new page must function like the old page, minus bugs, of course.) The integration of the javascript to accomplish the editing functions on the client side makes for a good UX (assuming they work correctly). I can probably accomplish that same thing with AJAX and/or jQuery, but I'm wondering if I'm really gaining anything here.

How would you handle this?

Answer 1

That's a really complex question you're posing. The main issue is right there at the end:

I'm wondering if I'm really gaining anything here.

Is the modification you need to make a small mod? or is it large? How much will you have to maintain this in the future?

You'll only realize dividends on your effort with future modifications. If you're never touching this system again, re-writing won't realize any benefits.

Answer 2

You also have to take into consideration a couple of other issues:

• How critical are the defects?
• How much time to do you have to get this thing fixed?
• How long will it take you to correct the defects in classic ASP?
• How long will it take you to convert the entire thing to ASP.NET?
• At the end of the whole thing, will anyone care which platform it's implemented in? That is, will they still be able to get their work done? Because, at the end of the day, that's all that really matters.

ASP.NET, while a wonderful thing, is not a silver bullet. If you're spinning your wheels, you're not being productive, and no one's getting a fixed product in a reasonable timeframe. It's like refactoring code just for the sake of refactoring it. It doesn't fix any defects, but darn does the code look pretty.

My advice to you: stick with classic ASP until you get the bugs out. THEN port it to ASP.NET. I'd much rather port a fixed product than a broken one.

Answer 3

I have worked in projects in which we "converted" a classic ASP application into a .NET application. This is what we did:

1. Made a copy of the classic ASP files and then used the automated conversion feature from Visual Studio to convert this new copy into a .NET application.
2. Listed the .NET features we wanted to take advantage of in this new application and then found the correct places in the application to implement them.
3. Re-wrote code where needed to take full advantage of such features.
4. Refactored existing classic ASP code to avoid re-inventing the wheel where it was not needed.
5. Tested everything and then ran both applications in parallel until we felt comfortable that the new .NET application was running as expected.