Switching Painlessly from IIS to Apache?

Sheik Yerboutii asks: "The recent downtime caused by the Code Red and NIMDA worms has prompted my Manager to start considering moving away from IIS to Apache. I've been tasked with finding out just how difficult it will be to move to the new webserver. I've got to find out things like how to install and configure it (relatively easy, it's all documented at www.apache.org) but also, things like what do we de now that we've been working in VBScript ASP for about 6 moths?" We posted a similar question to this one, just over a year ago. Any changes or additions to the advice given in that discussion?

"I've read that Apache::ASP exists and that's got something to do with mod_perl but now I'm going in circles figuring out how to make this thing work. I also can't find straight answers on things like if we make the cut over, will we have to convert the VBScript ASP to Perl ASP?

Can anyone relay their experiences with cutting from IIS to Apache? Running ASP with Apache? Most importantly, what are the best resources available for Apache administrators? (hopefully something with a discussion forum)"

Comments

Re:Check out JediTrainer's comments

[JediTrainer]

Heh - you beat me to it! Good job!

I was quite serious about that post. I made it sound easy (and, well - it wasn't THAT hard). The hardest part was for that 8 months the work was more difficult. We had to implement nearly everything from scratch again, which was a bit of a pain (ie: replacing the working and debugged with new untested code).

The advantage, however, was that because we were effectively rewriting the application and phasing out the old one, we had the opportunity to not make the same mistakes that had been left in the old ASP/COM version of our program. What we lost in time porting the app we gained in program efficiency and ease of maintenance later (or, for us, now). Keep in mind that I stuck my neck out on the line - the bosses would have had my head had this plan backfired. This app was in production the entire time during the conversion - 100% uptime and new components were phased in over this period of time.

Before you start on anything like this, do take the time to carefully plan your approach (technologies, API layout, modularization, maintaining flexibility etc). I spent about a month's time planning how my team was going to solve this conversion project, and this time has paid off tenfold in the end. I can honestly say that we'd already have been dead had we stuck with the old model - the workload with the amount of staff we have, along with the relative unmaintainability and inflexibility of the old code (we're seeing a lot of demand for customization to our app), would have made it impossible to keep up. Properly designed modules made customization a breeze - simply extend a couple of classes and throw in custom code for that customer.

If you have more specific questions, I'd love to help give you some insight. Obviously I'd be under some NDA so I can't reveal exactly what our app does, but I can certainly point you in the right directions for accomplishing what you want to do. Send a note to arozeluk at home period com.