The IIS to Apache migration process needs to be handled with the same care and perspective as the process of migrating desktops and their attendant applications. In some cases, IIS to Apache may be even more difficult and may have a larger impact on users and administrators.
In this article, I'll talk about the process of migrating a site from IIS to Apache, with Red Hat Linux as the specific target. Many of the bits of advice and guided suggestions here will probably work on Linux generally, but Red Hat's breadth of usage and relative popularity with ex-Windows admins makes it a good example.
The first step in planning this migration is to take a tally of what exactly is being migrated. No migration should ever be done blind; know exactly the depth and scope of what you're getting into before you attempt it.
Here's a rundown of the major categories of what can be migrated, in ascending order of complexity:
Static content. Static content is any file that can be delivered by a Web server without major transformation -- static HTML pages, images and some multimedia files, for example. Files that use server-side includes also fit roughly into this category, because SSIs are meant to behave fairly consistently across platforms. Migrating a site that consists entirely of static content should not pose a major investment of time and effort unless configuration settings (permissions, etc.) need to be copied as well.
Web server settings. You won't always have one-to-one mapping of settings between IIS and Apache. This means you need to think conceptually about settings instead of specifically -- i.e., if you know the /users directory in your IIS Web server is permissions-protected, then you need to recreate that on Apache in its own way.
Applications. The difficulty of migrating an application from IIS to Apache will depend on the platform or language used. Any language that is platform-neutral should be a snap; for instance, a Perl application that doesn't have a database back end can be migrated intact simply by moving the application directory and ensuring that Perl is configured correctly on the target computer. Note that .NET applications can be migrated to Linux to some degree; see the section below for more details on this.
Database-driven content. Any Web application that depends on database-driven content will pose a challenge, but how much of a challenge will depend on whether the database engine itself exists on Linux. In short, it's like the application-language issue; if you're using a database solution that exists on both Windows and Linux (MySQL, for instance), migrating the database along with the application itself is trivial and can be done mostly by exporting the database on one platform and importing it on the other. If you're using a proprietary database (SQL Server), then the whole database end of the application may need to be re-worked or at least hosted provisionally on the Windows server until a full migration can be worked out.
Platform-dependent code. This includes ISAPI, ActiveX or COM+ .DLLs, which cannot be moved to Linux as-is. Any IIS application that depends on .DLLs of some kind will need to be reworked from the ground up. Fortunately, many of the functions handled by ISAPI .DLLs can be performed by existing Apache modules, so in the long run, the problem can be handled in the same conceptual way as migrating Web server settings.
Automating a migration
The bigger the site, the less inclined anyone would be to perform the migration process manually. Red Hat doesn't come with native tools to perform a migration from IIS, but a few third-party companies have stepped into the gap.
One commonly referenced tool for performing IIS-to-Apache migration is Versora Progression Web, which automates the process of copying an IIS installation to a matching Apache installation. A broader migration system is LSP, which is designed to migrate an entire Windows server to a Linux server -- file shares, users, mailboxes -- but also migrates an existing IIS setup to a matching Apache setup.
Note that these tools are not written to migrate IIS applications across platforms; they're more for migrating directories, permissions and static documents to Apache. If you have an ASP.NET application, especially something with a database-driven backend, running one of these tools will not mean you'll have the exact same thing running under Apache.
ASP and ASP.NET applications
ASP and .NET are two widely used but application platforms for IIS, and because they're proprietary, they pose a bit of a stumbling block.
You can take one of two basic approaches to migrate an ASP.NET application to Apache. The first is to use Mono, the open-source implementation of the .NET framework, which will allow just about any non-binary-dependent application (i.e., anything that doesn't require a custom ISAPI .DLL) to run natively. The "classic" ASP programming framework can also be run in Apache using the Apache::ASP extension, and Sun has its own Java-based ASP system as well.
The second alternative -- which typically involves a great deal more work -- is to leave the existing application behind entirely and redesign the application from the ground up on another platform. This obviously is outside the scope of this article, but if you're determined to do it, this approach will get you completely away from any proprietary software issues. For converting classic ASP applications wholesale, asp2php converts ASP into the PHP language.
Some Windows admins might already have experience with Apache, because it's available in a Windows build that is only slightly different from its Linux edition. If at all possible, you should get some experience with Apache on Red Hat before you begin to migrate, or you should at least conduct some kind of staging of the migration on a test machine. One easy way to do this is to run Red Hat in a virtual machine.
VMware has pre-configured virtual machines called virtual appliances that can be downloaded and run as-is with most everything needed to host Apache applications. VMware even lists several Red Hat-specific virtual appliances on its Web site: Enterprise, Red Hat 6.2 and the Red Hat Application Stack -- the latter being an appealing all-in-one bundle that includes MySQL (among many other goodies).
Another convenient thing about virtual-machine technology is that it provides a ready-made way to create a staging environment for an IIS migration. You can set up a virtual machine, stage the migration to the VM, test it there (even theoretically with a live load) and then copy the Apache setup to a live machine once you're satisfied. A VM can also be used to handle many other tasks covered here -- for instance, migrating ASP or .NET applications across platforms.
When migrating away from IIS, you'll get the best results if you apply the same strategies you would in any cross-platform migration: go slow, stage things whenever possible and don't assume you can predict the results of anything out of hand.
One of the advantages of using Red Hat as your migration target is that you have a wealth of technical resources to draw on and a platform that has many years of community development and integrity behind it.
Did you find this tip helpful? What other tips would you like to see? Email us and let us know!
This was first published in January 2007