Ever since Netcraft has started tracking statistics
regarding Web server usage, IIS has never beaten Apache when it comes to the
number of sites using the two Web servers. Even in early 2002, when Apache took
a dip while IIS increased in popularity, there was still a 30% gap between them.
Today (in early March 2006), Apache enjoys almost a 50% lead over IIS. Of
course, these statistics take into consideration all of the free and cheap
hosting services that use Apache and don’t consider internal use of IIS in many
companies.

That said, 50% is still a huge gap! And, there are a number
of reasons that your company might consider making the jump from an IIS
solution to Apache. I’ll quickly explain some of these reasons and then go over
some of the ramifications of such a decision and provide some advice for
mitigating problems related to this kind of a move.

Since the focus of this article is on moving from IIS to
Apache, I’m not going to spend a lot of time balancing the argument. That is,
while I personally consider both IIS and Apache to be worthy products, I’m
leaning toward Apache, which is the intended focus of this article.

Why change?

First off, IIS is a good Web server, and it’s getting better
with each new version, so why make a jump from a perfectly good Web server to
Apache? Moreover, with each new
iteration, Microsoft improves the security of IIS, making the case for change a
little less compelling. And, for some organizations–particularly those that
have a heavy reliance on other Microsoft tools–a change would simply not make
any sense.

Now, for those of you that do not have tools–such as SQL
Server Reporting Services–that are tightly tied to IIS, are there compelling
arguments for making the leap?

The answer: If you have a need to operate in a heterogeneous
environment, and have a need to choose a single Web server to use across all
platforms, you simply can’t beat Apache. The lines have blurred with regard to
other issues that used to set Apache apart from IIS, including the security and
manageability of the servers.

Another answer: If you need to implement a significant Web
service and want to be able to do so with a minimal license cost, consider
Apache on Linux for your solution.

For sake of argument (and to get on to the meat!), I’m going
to assume that your organization has made the decision to at least consider
moving from IIS to Apache and you want to know what to expect should you decide
to begin an actual migration.

Plan for ASP

One significant hindrance to migration efforts from IIS to
Apache lies with the issue of dynamic scripting language choice. For most
Windows Web environment, ASP or ASP.NET are the languages of choice since they
are very well supported and included with IIS. Unfortunately, both are native
to Windows and Microsoft has not moved them outside this playground. However,
there are a number of ways that you can still make the move to the open source
Apache/Linux combination (or Apache/Windows, for that matter).

Change to another language

If you only use ASP casually on your site, you can opt to
migrate your ASP code to another language, such as PHP. With smaller sites,
this is probably best handled manually, but for larger sites, the prospect of
converting code could be a major undertaking. However, there are some tools
available that can help you with a conversion. For example, asp2php is a free tool that can help you
make this leap. While this free tool is only provided to help you make the move (it doesn’t do it all, by any means), it can
help you avoid some of the tedious task of recoding hundreds of pages of code.

Also consider the use of a Java-based framework for a site
if you decide to take the plunge and migrate to another language. Apache’s Tomcat provides you with a free, open
source servlet container to help make this change.

If you do decide to make the jump to a new language,
remember that it’s not the syntax that was difficult to write in the first
place, but it was the logic. Since you already have the logic completely
documented in your ASP code, migrating to another language shouldn’t be
horrendously difficult.

Keep ASP and still run Apache

One great thing about open source and an open market is that
for just about any need, you can find a reasonable solution. In the case of
continuing to run ASP code after moving to Apache, there are many solutions
available for you to peruse.

The most well-known solution, Chilisoft ASP, is now a
product from Sun called Sun Java System Active Server Pages 4.0 and provides
ASP support for certain versions of Solaris, Red Hat Enterprise Linux, HP-UX,
AIX and Windows (without IIS, of course). Sun Java System ASP 4.0 supports
Apache 1.3 and 2.0. Sun’s solution also provides ADO support as well as a full line of ODBC
database drivers for use with the product. Among the ODBC database drivers
includes are drivers that allows Sun’s product with work with both SQL Server
and Microsoft Access databases.

As with anything, a conversion process using this software
is probably not going to be 100% perfect and you may need to make some minor
code changes to make everything work exactly as you expect, and there are some
instance–if you use Visual Basic objects, for example–in which this solution
won’t work at all.

Another option is to use Apache’s mod_perl module and a
perl-based solution called Apache::ASP.
This is not as clean a solution as others, so do a lot of research before you
decide on this free solution.

Learn a new management style

If you’re an IIS guru, the Internet Services Manager has
probably become a familiar tool for you. In IIS 6.0, the Internet Services
Manager manipulates the XML-based IIS metabase. What Apache administrators have
been able to enjoy for a very long time is the manipulation of server
configuration files using nothing more than a text editor. While this is
possible in IIS 6.0, it’s far from a well-known fact! In versions of IIS prior to IIS 6.0, the
metabase was a binary file that required special tools to manipulate.

Apache, on the other hand, using simple, (usually) readable,
plain-text configuration files to handle 100% of its configuration. When you
need to change the path you’re your server’s document root file, you just load
up httpd.conf (Apache’s main configuration file) into a text editor, look for
the DocumentRoot directive and change the path.

Why is this a good thing?
First off, you don’t need any special tools to make configuration
changes to your Web server. GUI-based tools, at times, can make the
reconfiguration job more difficult.

Second, for a production Web server, the corruption of a
single file should not result in an unusable Web server. While you always need
to back up configuration files, it’s easier to back up the contents of a
text-based configuration file in multiple places. For example, for Apache, you
can print the contents of your httpd.conf file after you make changes.

On the flip side of the complexity equation, if you do like
Apache’s text-based approach, you’d be prudent to install some kind of
versioning system so that you can easily track changes that are made to these
files. That’s one thing you don’t really have to contend with under Windows
since it’s a little harder to make mistakes that bring the system down that you
have trouble finding later on.

Note: The upcoming IIS 7.0 is supposed to permanently do
away with both the IIS metabase and Internet Services Manager in favor of
.config files for IIS’ configuration and a new tool to manipulate the settings
of the .config files.

Of course, Windows admins are very used to GUI-based
management tools so converting to a text-based approach may require some time
and training. Make sure to allow yourself enough time to become familiar with
Apache’s various directives and commands.

Go modular

There’s a module for PHP, a module for Perl, a module for
MySQL, a module for this and a module for that. Simply put, Apache is nothing
if not incredibly modular! That Apache
approach is this: Install only what you need and nothing else. This seriously
reduces the attack surface of the Web server and also improves performance
since you’re only running what you need. Yes, you can disable certain IIS services,
particularly under IIS 6.0, but a default IIS 6.0 installation is still less
efficient than a default Apache installation.

What do you need to learn here? First off, everything in Apache is handled through
some kind of module. Want database access?
Get a module. Want scripting? Get a module. Want proxy services? Get a
module. This is definitely a good way to handle this kind of service, but
Windows administrators may not be used to the flexibility offered by a system
like Apache. There are hundreds of modules available that help you make Apache
do new and interesting things. For example, with IIS, you’re somewhat limited
with your authentication methods. With Apache, as of this writing, there were
64 modules listed on the Apache Module Registry that are all designed to extend
Apache’s authentication methods to other systems, including PostgreSQL
databases, IMAP servers, LDAP directories, NT servers, Oracle databases and a
whole lot more.

In total, the Apache Module Registry has well over 400
modules all designed to help Apache help you meet your goals.

This brings up the issue of how you handle direct
connections to things like Microsoft SQL Server, which is commonly used with
IIS. An open source called–FreeTDS–provides
your Linux or IIS-less Windows Server the capability to continue to communication
directly with SQL (or Sybase) servers.

Or, while you migrate from IIS, you could also consider
migrating to a lower cost database such as MySQL or PostgreSQL.

Note: IIS 7.0 is also supposed to “go modular” a
la Apache.

As for other modules, such as IIS-specific ISAPI modules,
you will need to migrate these to something that works outside of IIS, such as
NSAPI. Apache does includes the mod_isapi module which provides basic ISAPI
extensions, but not support for ISAPI filters.

Understand platform differences

Index.htm vs. index.html:
The difference is subtle, but will bite you if you don’t notice it. Apache’s
default document is “index.html” whereas IIS uses “default.htm”.
Further, Windows systems use path names with backslashes while Linux and UNIX
use normal slashes.

As you migrate your site, make sure to be aware of platform
differences and adjust appropriately. I would recommend adding another default
document named “index.htm” to your Apache configuration file and also
allow Apache to process files with both “.htm” and “.html”
extensions.

The birds-eye steps

The migration from IIS to Apache is not trivial, but it can
be broken down into just a few high-level decision-making steps.

Decide on a platform

The good news: Apache
runs on practically anything you have. Run it on Windows, Linux, UNIX, NetWare,
and it will work. The bad news: This makes your decision about where to run
Apache a little more difficult.

After all, with IIS, your platform decision was made for you.
With Apache, you’re free to choose to run Apache anywhere you like. The answer
to this question lies in your overall environment. If you’re open to trying
open source in your environment, or you’re trying to move to open source, consider
Linux. If you’re only moving away from IIS for security reasons, consider
sticking with Windows.

Decide the future for scripting in your organization

If your IIS servers use ASP, I highly recommend you try Sun’s
ASP server product. It does a surprisingly good job at working with your ASP
code on any platform.

If you’re not doing any scripting yet and are serving just
static pages, the point here is moot, but, if you do take up scripting, look
for something pervasive like Java or PHP.

Choose your database

While there is no reason to move of SQL Server, if you’re in
an organization committed to moving off closed-source products, consider the
use of MySQL or PostgreSQL for your database needs. I’ve used PostgreSQL for
some significant databases and have directly migrated SQL Server databases to
the product and have found it to be a very worthy replacement.

Find modules

Does your IIS server authenticate users against Active
Directory? You’ll need Apache’s mod_ldap.
Go through your entire site and ask yourself exactly how it works what locate
the Apache modules that you will need to support your business.

Install, migrate, and test!

Once you’ve made all of your selections, install your new
servers, install the supporting services, such as Apache modules or Sun ASP,
migrate your code and test it thoroughly.

Take it in baby steps

As you would expect, any conversion like this can’t be
broken down into two or three steps and called good, except for the simplest of
sites. Decide if it’s worth taking the plunge and then plan your strategy very
well. With Apache’s wealth of support resources, you will probably be able to
conquer any problem that comes your way.