Migrating from IIS to Apache

Paul DuBois

Document revision: 1.01
Last update: 2003-01-25

Table of Contents


Microsoft's presence in the computing market is well-established, with Windows running on the vast majority of desktop systems worldwide. In the server arena, Microsoft's segment is much smaller by comparison due to prior market penetration by other vendors such as Sun and HP, as well as by Open Source operating systems like Linux and variants of BSD Unix. This is a clear opportunity for Microsoft, which has been making a strong push for the hearts, minds, and pocketbooks of administrators responsible for organizational central computing services. For example, a recent Microsoft advertisement features video showing a slate of servers running Windows 2000 humming in a machine room while the voice-over soothingly assures the viewer that the servers have been running "for days" without attention. (Presumably this is intended to assuage the concerns of users familiar with daily lockups and crashes like the "blue screen of death" that commonly plague earlier versions of Windows.) It's clear that Microsoft intends to position its offerings as providing the systems of choice all along the computing spectrum. One particular part of that spectrum that has become especially popular in recent years is the organizational or enterprise web site, which generally requires at least three components:

Microsoft has been active in the web service market and has product offerings to cover each of these components. A typical recipe for setting up shop uses Internet Information Server (IIS) as the web server, Access or SQL Server as the database, and Active Server Pages (ASP) as the scripting language that ties it all together. It's easy to get started in this direction, especially now that Microsoft bundles IIS with its systems. (IIS is tightly integrated with Windows 2000 and Windows XP.) By running a recent version of Windows, you're already on your way to setting up a web site, and Microsoft is happy to provide the other components as well, as add-on products.

Not everyone builds a web site around IIS, of course. The most visible alternative is Apache, which is the most widely used server in the world. According to Netcraft, Apache powers more than half the web sites available on the Internet. Of such sites that are database-backed, a combination of tools that has proven especially popular is the pairing of Apache with the MySQL database system, which can be integrated by means of scripting languages such as PHP or Perl.

This article takes a look at Microsoft's product offerings for web site development based on IIS, and compares them to the corresponding Apache site components. Apache, MySQL, and scripting languages such as PHP and Perl are best-of-breed components in their respective categories for web site development. When these products are placed in head-to-head competition with the corresponding components of an IIS-based site, they not only perform better at lower cost, but also give you wider latitude to make your own operating system and server hardware choices.

The proposition presented here is that organizations currently running a web site based on IIS have much to gain by considering other options. The contents of the article will be most pertinent to groups operating under the following circumstances:

In addition, this article may provide food for thought for organizations that are satisfied with their current IIS-based setup, but still interested in knowing about other options.

The next section of the article discusses some reasons to consider alternatives to IIS. For groups that are interested in moving IIS-based web services to Apache, a later section suggests some migration strategies.

Reasons To Consider Alternatives to IIS

Running a web site can be a complex business, and many factors go into assessing the site's effectiveness. This section discusses several aspects of web site development, comparing an IIS-based site to one based on Apache.

Choice in Selecting System Configuration

Developing a system to meet the needs of your site requires that you be able to choose the best tools for the job. This includes not only your web development components, but your operating system and the server hardware that the site runs on. Thus, the choice of what software to use for developing your web site is not a decision made in a vacuum. In general, tools that can be deployed only on one platform constrain your options, whereas tools that are platform neutral allow you to consider a wider range of alternatives.

In this regard, IIS exhibits a complete absence of platform neutrality. Its users have a choice of running it only under Windows--that is, no choice. This is reminiscent of Henry Ford's remark about his Model T automobiles that customers could have in any color they desired, "so long as it's black." Similarly, you can run any operating system you like with IIS, so long as it's Windows. This operating system lock-in has a ripple effect as well: If you can run only Windows, you can choose only server hardware that Windows supports. Needless to say, if the consequence of selecting IIS is to determine your operating system and hardware choices as well, it rather narrows your options. The same kind of lock-in occurs with Access and SQL Server as well, which also are Windows-only products.

By contrast, an Apache-based site provides developers with more of a choice. If you want to run Windows, you can; Apache, MySQL, PHP, and Perl all support it. But if you want to go with Unix or Linux instead, you can do that, too. This freer choice of operating system translates directly into a broader selection of server hardware. You can choose hardware that Windows supports if you like, but it's also possible to select hardware supported by Unix or Linux--for example, if you require high-end servers beyond anything that Windows is capable of running on.


Customers expect to be able to visit an organization's web site at any time, not be turned away because the site is down or the server is having problems. Earlier, this article mentioned a Microsoft advertisement that pointed out how Windows-based servers can run "for days" without attention. The ad projects an image of stability and reliability, but an additional--and no doubt unintentional--message is that the ability to run for days is a new thing for Windows. This may indeed be a novel phenomenon in the Windows world, where a common and well-known strategy among NT administrators is to reboot servers every few days to keep them from failing or locking up. But elsewhere in the computing community, long-running systems are taken for granted. Administrators who run Unix or Linux are used to measuring uptime in terms of weeks or months, and sometimes years. In this context, an uptime of days is decidedly unimpressive.

Aside from differences in typical uptime under normal use, the tight integration of IIS into Windows has a negative impact on system availability--the familiar sequence that after applying a patch or update, the entire system must be rebooted. Worse yet, you may need to reapply patches after changing the system configuration, leading to further downtime. With Apache, reconfiguration takes only seconds, because you restart only that program rather than the entire machine on which it runs.

Security Concerns

Security is one of the most important aspects of any Internet-based system. The consequences of being hacked are considerable, ranging from the inconvenience of having to reload software deleted by or compromised by an attacker to outright theft or destruction of sensitive information. Yet, security is perhaps the area in which IIS is weakest--so much so that insiders refer to IIS as "It Isn't Secure." New exploits often spread worldwide with an astonishing rapidity, sometimes crippling systems to the point where entire networks must be shut down or disconnected from the Internet while system administrators scramble to correct the problems and deal with the damage. This may provide job security, but certainly in an unwelcome form.

The recent waves of Code Red and Nimda attacks that infected hundreds of thousands of IIS servers illustrate the problem well. Other IIS exploits, such as buffer overrun attacks against its printing and indexing functions that give the intruder complete control of the server host, also are indicative of IIS's mediocre security record. But these incidents should be viewed in their surrounding context. They actually demonstrate but one aspect of a larger issue, which is the general failure of Windows-based products to seriously address the security concerns of the administrators responsible for their use. To appreciate the full extent of the problem (and thus the real basis for concern), consider the larger picture. IIS vulnerabilities are symptomatic of a history that goes back years, to the Melissa and ILoveYou email viruses that targeted Outlook and Exchange users and debilitated mail systems worldwide after they were released, and to the inception before that of macro viruses transmitted by means of Word and Excel documents. Virtually all of the most damaging exploits in recent times involve one vendor's products. These incidents are not exceptions, they are part of a pattern. The administrator who wearies after attempting to cope with these myriad vulnerabilities may be forgiven for concluding that security simply was not a high priority in the design of these products, and that perhaps their most effective function is to serve as a vector for the transmission of malicious and dangerous attack software.

In defense of Microsoft, one might argue that the number of exploits against Windows systems compared to those against Unix or Linux reflects nothing more than the prevalence of Windows in the market. But if that is so, it's to be expected that the continual scrutiny given to its products provides feedback that should allow Microsoft to significantly harden them against attack. That new exploits arise no less frequently now than ever indicates that this has not happened. In any event, if scope of deployment correlates to the number of exploits expected to occur, weaknesses should be discovered most often for Apache, which is much more popular than IIS. Yet the majority of breaches occur at IIS sites, while Apache enjoys an excellent reputation for security.

Perhaps it is the case that inexperienced IIS administrators just do not make use of the patches that are available, and thus that problems are due to failure to apply the proper safeguards? There may be something to this. On the other hand, the number of patches that Microsoft finds it necessary to issue make the administrator's life overly difficult, especially in shops that run several IIS servers. Applying patches can become a full-time pursuit, simply because there are so many of them. This makes it difficult to keep up.

At any rate, if inexperienced administrators in the field are most likely to have security problems, who should be least likely? Microsoft's own people, of course, such as those responsible for Passport, the web-based service that Microsoft now champions as a secure repository for storing consumer information. Apparently experience is not enough, however; Passport has already had to be shut down temporarily over issues that left consumer financial data vulnerable. If Microsoft's own staff have trouble running its products in a secure fashion, where does that leave the rest of us? But the most disturbing aspect of this incident is that it illustrates an attitude toward security that should give administrators pause. In the wake of publicity about the Passport shutdown, Microsoft first attempted to shift the blame, characterizing the group that publicized the vulnerability as irresponsible and saying that the group should have notified Microsoft instead. After it came to light that Microsoft had in fact been notified and did nothing until public disclosure of the security hole, it was forced to backtrack and acknowledge the true course of events leading to the shutdown.

This is significant because if you are going to rely on a product and commit confidential business resources to it, you want to know that the vendor's claims about the security of the product are trustworthy. When Microsoft says that it cares a great deal about security, it's not clear that such claims can be taken at face value, given events such as those surrounding the Passport incident. This is worth keeping in mind when evaluating other security-related claims. For example, Microsoft introduced its Secure Windows Initiative for Windows 2000, and more recently its Strategic Technology Protection Program. However, it remains unclear what the practical effect of these will be. For example, Windows 2000 and Windows XP are subject to the concepts Microsoft has laid out in the Initiative, and thus one might expect them to be more secure. On the other hand, these versions of Windows have had IIS tightly integrated into them, and IIS is based on legacy code that predates Windows 2000. Given the track record of IIS, this is not a promising basis for better security, which is only as good as the weakest link.

Granted, maintaining security is an ongoing task, and it's never trivial. But some systems make the job easier than others. In the arena of security, Apache unquestionably provides a superior platform for web development compared to IIS. One reason that Apache is more secure than IIS is that it's designed using a different philosophy. Apache developers proactively seek to identify and address security issues They don't wait to be publicly embarrassed into doing so.

An Apache server should not be considered secure just because it is Apache, of course. If its administrator pays no attention to security issues, problems are still likely to occur. But the default installation is more secure, and Apache certainly won't need several patches right out of the box, or the continual updating at the same rate as an IIS server. Apache works with you to help maintain security. It's not a problematic piece of software over which you must cast a wary eye, ever vigilant against the next new wave of infection. The history of Apache is that it's an asset, not a liability. The history of IIS points to the likelihood that the product will continue to be a source of problems, and that it may be prudent to consider a change. After all, who really pays the price for security breaches? The organizations that use insecure products, not the one that markets them. Customers have little choice but to swallow hard and hope the damage will be minimal--unless they make another choice.


IIS is included with Windows 2000 and Windows XP, so a site consisting of static pages can be built using no additional software. But a truly dynamic site really necessitates the use of a database back end, and for IIS, the two common choices--Access or SQL Server--must be purchased as add-ons. The cost of alternative products, such as the Apache web server and the MySQL database engine, is modest by comparison. Another factor to take into account is that acquisition costs are only part of the total cost of ownership. For example, many costs can arise from security-related issues:

Being known for running insecure systems may also result in less easily quantifiable costs, such as a tarnished reputation. (Though even here there may be quantifiable aspects as well. For example, Wurzler Underwriting Managers announced in April 2001 that it would apply a surcharge on premiums for Windows NT systems used to provide Internet services, based on the observation that NT boxes are more likely to be broken into than systems running Unix or Linux.)

All in all, the total cost of ownership may be very high indeed, even when the up-front outlay is low.

Performance and Features

In a web service environment, the most resource intensive component is likely to be the database used as the back end for creating dynamic content, especially for complex queries. In this setting, MySQL is one of the fastest databases available, if not the fastest. Compared to Access, which has a number of shortcomings, an alternative database engine like MySQL offers a number of advantages for web site developers. These benefits are outlined in another article, "Migrating from Microsoft Access to MySQL" (see the "Resources" section). They include better performance in networked and multiple-client environments, ability to handle larger databases, and platform neutrality.

When a more heavy-duty database engine is required, IIS sites often use SQL Server in preference to Access. Like MySQL, SQL Server is more capable than Access and provides more robust performance under significant load. As a result, choosing between MySQL and SQL Server is not as easy as choosing between MySQL and Access. Nevertheless, MySQL is attractive in terms of performance, cost, ease of use, and support. (And of course if you want to run your site on something other than Windows, SQL Server will not work at all.) When evaluating the features of each database, be sure to review current materials, because older critiques of either product may no longer apply. For example, a common complaint against MySQL in the past has been its lack of support for ACID transactions, a capability crucial for business application. This criticism is no longer valid, because transaction capabilities and full ACID compliance are now provided by the InnoDB table handler.

Migration Strategies

Issues discussed earlier in the article such as security and platform neutrality are most important when deciding whether or not to make a switch from IIS to Apache. Other considerations, such as compatibility issues, come into play more when planning how to make the switch. Changing web service platforms isn't a trivial thing and should be planned carefully. To reduce the effort required for migration, consider in advance the problems you'll face, your options for overcoming them, and what help is available in making the switch. Some principles to keep in mind are as follows:

Use Portable Interfaces Prior To Making the Transition

Try to use portable database interfaces in your applications to make it easier to switch database engines. This is especially important if you're planning to make a transition at some point down the road but are continuing to develop applications on the existing site in the meantime. Using portable interfaces for your applications will allow them to be migrated more easily when the transition does occur. Code encapsulation is important, too. For example, applications should make connections to the database using a library call, not by means of connection parameters wired into individual scripts. This makes it easier to connect to a different database later by changing the library call rather than multiple scripts.

It still will be useful to perform a feature comparison between your old database and MySQL to identify SQL constructs where porting effort is likely to be concentrated. To take one instance, if a site uses sub-selects heavily, this will be a concern. MySQL does not support sub-selects until version 4.1, so if you run an earlier version, queries that use sub-selects will need to be rewritten in other forms. (For example, many NOT IN queries can be expressed as LEFT JOIN operations.)

Leverage What You Know

Three ways to use existing knowledge and experience to minimize transition shock are to retain some components of your existing setup, to use new components that are similar to those you're using now, and to use a development environment that works under both the old and new sites.

For example, you can retain Windows as the underlying operating system while switching the web site components that run on top of it. If you set up a test bed system this way, it allows developers to continue using a familiar operating system while moving to Apache and MySQL. This is a smaller leap than making the jump to a different operating system as the same time. As you gain experience with the new site development tools, it becomes a less imposing prospect to migrate from Windows to Unix or Linux. (Although all the components of an Apache-based site can run under Windows, migrating to Unix or Linux provides better overall stability and performance.)

If you want to retain ASP as the site scripting language, consider using a compatibility engine such as Chili!Soft ASP. This engine runs under Apache, works on Windows, Unix, or Linux, and includes a MySQL driver. Thus, it allows use of a familiar language while opening up other avenues of deployment for your web applications. Shops with no particular reason to use only ASP can still apply staff expertise with ASP to new languages. If you like the embedded-tags approach of ASP, candidates that employ a similar markup-tag structure include PHP and the Apache::ASP Perl module. Each of these allow you to write pages that consist of mixed HTML and executable code. (Apache::ASP requires the use of the mod_perl Apache module. However, it's a good idea to use mod_perl anyway, because it provides a dramatic speedup for Perl scripts running under Apache.)

If you want to explore Java-based options, JSP (JavaServer Pages) is even more like ASP than is PHP in terms of its scripting syntax. JSP does require a servlet container such as Tomcat, which is freely available at jakarta.apache.org and can be installed and configured relatively easily. You can even set up a site such that Apache and Tomcat cooperate, with Apache handling all requests initially and passing through requests for JSP pages to Tomcat. This requires somewhat more configuration effort initially, of course, but it give visitors to your site a more uniform view of your installation as a single server rather than two disparate servers.

If your developers are not fully familiar with the new tools you're considering, you may also find it a good idea to hire outside help to assist in making the transition and helping your staff get up to speed. (The expense may well be offset by no longer having to allocate staff time to dealing with the IIS "patch of the week" dance.)

Use Conversion Tools

You may be able to use conversion tools to migrate your data to MySQL and to convert existing applications for use with the new site:


Organizations have a choice in determining which products to use for web site development, and while Microsoft's IIS is a popular web server, alternatives are available that are superior in terms of reliability, security, and cost. In particular, the combination of Apache and MySQL is an attractive option, with benefits that range from greater flexibility, performance, and security, to lower cost and maintenance. Tools are available to help make the transition from IIS to Apache; the article suggests some migration paths.


The following references provide more information about topics discussed in this article.