Letting Go of Windows NT and 2000
Linux Migration Made Simple

Running a Microsoft Windows NT server these days is a brave (or, perhaps, stupid) thing to do: Support for the product has finished, and as far as Microsoft is concerned, the product should be put in a rest home for retired software. Windows Server 2000 is also getting long in the tooth, and in a few years it too will reach the end of its support lifecycle and be looking for its rocking chair and slippers.

So if you work for one of the many organizations around the world still running NT and 2000, like it or not, you are soon going to have to migrate to another operating system.

There are many reasons to consider migrating some or all of your data center servers to Linux, and we won't go into them here. But if you do decide to go open source, some ways of going about it are better than others.

It may sound boring and trite, but the one thing which may dictate the success or failure of a whole migration project is the initial planning stage. Before you can embark on a migration (any migration), you must decide the scope of the project. Are you planning to migrate only the Windows NT file and print servers and domain controllers to Linux, for example, or do you plan in the longer term to move your entire IT infrastructure (including Web and application servers and user desktops) to Linux?

For the initial phase, it's vital to build up a clear picture of what servers you will be replacing, what tasks they currently perform, and how they will accomplish those tasks using Linux.

The answers to these questions, together with the skill sets of the current IT staff, will help determine which Linux distribution to adopt. If staff members already have an extensive knowledge of a particular server-focused Linux distribution, it will likely influence your choice. If not, you'll want to choose a distribution with appropriate vendor support.

The next step is to estimate an approximate cost and time scale for the planned migration. The best way to do this is to break down the migration into as many manageable tasks as you can, and estimate a time and cost for each of these. The more detail you go into when describing these tasks, the more accurate your estimates are likely to be.

Later, in the pilot phase, the estimates can be checked and updated with the generated data.

Migrating an NT file/print server to Samba on Linux, should be fairly straightforward, and the potential to save money on Client Access Licenses (CALs) is high. "A properly configured Samba server is typically faster than a Windows NT or 2000 server, and clients will not be able to tell the difference," says Nick Lassonde, chief software architect at California-based Linux migration consultant Versora.

There are, however, a few pitfalls of which to be wary.

"The most common one comes from mapping security, as by default most Linux distributions only support POSIX security and not complete ACLs (access control lists). However, most modern file systems support ACLs, so this problem can be solved," he warns.

You'll probably also want to configure your file sever to authenticate against a domain controller, and there are plugins to achieve this. "Familiarize yourself with Samba's Vampire command," advises Lassonde. "This allows for automated migration of users from an NT domain controller to Samba."

In other words, it sucks the brains out of an NT server--hence the name. "Samba works flawlessly as an NT4 Domain Controller, but while Samba 4 has come a long way as an Active Directory Domain Controller, it is still not quite stable enough for production."

For Active Directory domains, it is possible to build Linux-based alternatives: IBM Software Group suggests a stack containing XAD (from PADL), LDAP, and Kerberos 5.0 running on Linux can serve as a viable alternative for Active Directory based Windows 200x domains, for example.

If your project involves migrating more of the data center to Linux, the next stage will probably be moving e-mail and messaging services from Microsoft Exchange to something like OpenXchange, which traditional Microsoft desktop clients can access, or IBM's Lotus Domino, which Outlook clients can also access.

Web and application server migration is much less straightforward. A number of questions must be asked:

* What server-side languages (e.g., ASP, ASP.NET, and PHP) are used on the server, and can these be used under Linux? If not, you will need to find a third-party solution or port the applications to Linux.

* What other machines do the servers connect to, and which be migrated first? For example, do you migrate a database to Linux first, or leave it on Windows?

* What sort of security options are required? Will you need to set up SSL connections on the new server? Will user authentication be local, or do you authenticate intranet users against a domain?

The obvious choice is to move from Microsoft's IIS Web server to an Apache Web server (which claims 65 percent of the Web server market according to Netcraft) and Linux-based databases including DB2, Ingres, MySQL, Oracle, and PostreSGL.

The hardest part of a Linux migration is migrating applications. If application migration is part of your project, it may be possible to use third-party solutions. Two examples of this are running ASP pages via Sun Java System Active Server Pages, or ASP.Net pages using Visual Mainwin, which provides a Windows library to which applications bind and run on Linux.

Tools that port applications from one environment to another are rarely worth adopting, says Lassonde. "Frequently the price of porting an application from one language to another will almost be the same as simply rewriting the application." He recommends leaving those applications on an ISS server, and then rewriting or porting them later in a more neutral language (such as Java) so future changes can be carried out more easily.

Whatever the scope of the migration project, before you start (especially if this is the first one you're attempting) bear in mind that however simple the project may seem, and however well prepared you think are, it's almost guaranteed problems will crop up.

Chances are, someone else will has had the same problems before. So at the very least, be sure to take full advantage of public support forums, and consider hiring an experienced migration consultant who--assuming he or she is any good--will have come across most of your problems before and will be able to suggest solutions to technical difficulties in minutes or hours that would otherwise take days or weeks to overcome.

By Paul Rubens