You are a system administrator for a small company—the captain of the firm’s computers. Doing your job well means that you may sail through the seas of information technologies unhindered, in short, the company’s IT infrastructure will stay in place. Should you mess up you will find that the email has stopped working, the web surfers are stranded and you have pinned your ship on the reefs and rocks that scatter the virtual world, or in other words, the company will not be functioning well and you be burning its money.

I will imagine that you are running some Microsoft Windows server solutions. You may have some GNU/Linux boxes here and there for the less important tasks but, in essence, yours is a Microsoft house.

Then it finally happens. The CEO has received one too many viruses on the system, or he has just read the latest Microsoft licensing terms. He has decided to bite the bullet. The company is to move over to Linux servers, and it’s you who are going to do it.

But before I record the number butterflies in your stomach at this point, or that exciting feeling you experience as you sail into, what to your company is, virgin waters, I would like to borrow a time machine and go back to a point at which an important question was asked. It is, I think, if not the most, one of the most important questions there is in IT—and that is: why?

The reason why? Free software migration strategy

There is no real place for dogma in system administration. If a system works for you, then that is the system to use. Also, everything has a cost, and often the smallest cost is for software licenses. This is not usually high enough to appear on the radar of the CFO—with the possible exception of the larger corporations. Companies who have moved to free software are not usually concerned about licensing costs, but in freedom. When you have a free software solution, you have control. Should your software vendor decide to double the support fees, or you simply fall out, you can simply switch vendors without switching systems. Should your software provider go broke, you don’t have to care. There is no problem getting the rights, or the source, to the software for others to support, and there would probably be no problem getting people to support it. An option that is rare in the proprietary world.

Using free software also means that you are no longer dependent on any single software vendor, or the good behaviour of one. Many proprietary companies hate the concept of free software because it relieves their customers’ dependence on them. Although this is bad for the software company due to the fact they would have to provide good service in order to keep their revenue, it can’t honestly be said that it’s not good for the customer.

Your investment is also more secure with free software than it is with proprietary systems. Free software never becomes obsolete. Once it is written it stays written—should the original author or company decide to dump that product, it can still be picked up by someone else. An example of this is the “RedHat GNU/Linux” products. With the advent of their enterprise suite and the community Fedora products they decided to drop support for their old RedHat retail product. However, others picked up the baton and you can still get good support for these products from sources other than RedHat. The same can’t be said about the old Windows products Microsoft has stopped supporting.

The strategy of any system deployment depends upon many things and is usually unique. The usual reasons for including a free software philosophy is not so much to reduce IT costs—which it tends to do anyway—but to increase your independence from individual IT vendors, protection of investment and freedom of choice. That’s not counting the fact you’d also have access to the source code, and could change the program to suit your own needs should your requirements warrant it. This is a concept totally alien to proprietary software.

Now that the why is answered, the next question is what.

The usual reasons for including a free software philosophy is not so much to reduce IT costs—which it tends to do anyway—but to increase your independence from individual IT vendors, protection of investment and freedom of choice

Sailing on the seas of system administration—responsibilities indeed

What to do? Analysis of free software migration

There are many IT server solutions, but I will be limiting the scope of this article to the assumption that you are an administrator of a Microsoft/IIS server deployment and you are migrating to a GNU/Linux one. However, This does not mean I am dismissing other free solutions such as OpenBSD.

The whats, and often the ifs, of switching to free software solutions largely depend upon what your requirements are. When comparing the two types of systems, not only can free software perform standard server functions as well as Microsoft’s offerings, but it usually does them better, including Windows’ own networking functions. It’s when transferring specialist legacy software from proprietary to free software systems, that you get the biggest problems. This legacy software is the software you currently have running, and whose functionality you would like to maintain, but is not available on the new platform. This is the biggest migration headache to free software causes. There are though, three possible solutions to this.

When comparing the two types of systems, not only can free software perform standard server functions as well as Microsoft’s offerings, but it usually does them better, including Windows’ own networking functions

The first, as my grandmother would say about television, is simply to do without it. After all, she survived perfectly well without computers and Star Wars. So, there’s no reason—she would contend—to have such reliance on the adventures of the Skywalkers and these new-fangled computer machines. Unfortunately, this solution is only feasible when the functionality of that legacy piece of software is near it’s shelf life, or if it simply no longer fits the task it was designed for. In other words, you can really only do with out it when it’s near being dumped anyway. There are circumstances where doing without could be the only solution, but this solution taken too far can attract employment costs, and while this may not have been a problem for my grandmother, it is one for a modern business. It’s also undesirable in so far as it defeats the purpose of having computers in the first place.

The second solution is to use some kind of “bridge” technology, such as an emulator like Wine, or virtualization software such as QEMU, or to have a machine running the old proprietary system in the corner. This is cumbersome to maintain, and can spoil the goals of migrating. These solutions should only be used in exceptional circumstances where the legacy application is small, non critical and not used very much.

The third solution is to rewrite the legacy software, have it rewritten or to find a new equivalent package that performs the same task, and then migrate the data from the old software to the new. This is, in my opinion, the best solution. However, this can be costly in programmer costs, software vendor costs or staff training costs. A large section of Microsoft’s inappropriately named “Get The Fact’s” campaign lingers on this and calls it, somewhat misleadingly, “interoperable costs”. These costs though are not reoccurring, they are one off, and quite often the costs you are forced to pay in upgrading and retraining on your current proprietary packages are not much cheaper than this. So it is this solution that is the way of the Jedi and where the force leads; where possible, chosen this route should be.

It is worth noting that free software packages, and those that run on free software operating systems, are encompassing a wider and wider set of functionality, procedures and environments. Java is cross platform, also Microsoft’s Dot-Net framework is no stranger to Linux due to Ximian’s Mono, and there are other instances of similar migrations. Like the disappearing bathwater down the plug hole, the functionality that Microsoft proprietary systems can perform that free software cannot is getting less and less.

Like the disappearing bathwater down the plug hole, the functionality that Microsoft proprietary systems can perform that free software cannot is getting less and less

Once the why and what has been solved, the next question is how.