Not all or nothing

Free and open source software is famously versatile. Think of just about any piece of software a business uses, and chances are there is an open source alternative. And if there isn't, then there probably will be within the year.

Being so versatile, open source software can be used in almost any situation, from desktop applications to cloud computing servers, which can often entice businesses down the path of a wholesale open source migration. The savings, flexibility and versatility of open source software are simply too good to miss out on. There are, however, risks in suddenly switching all systems over to open source software, and a gradual, mixed-environment approach is often a better way to go about it.

Before switching part, or even all, of a company's infrastructure over to open source software, it's essential to consider the effects of doing so.

Perhaps the most important thing to remember here is that although software migration is a technology change - usually falling under the IT department - it's a lot more than that. Migrating to open source software, or any new software for that matter, affects a number of areas within a business. The most important three are: technology, processes and people. The first is a given. The other two are perhaps less obvious, but where much of the pain will ultimately manifest.

It makes no sense to simply switch to open source unless the new software caters for current business processes. These pre-existing business processes should not be held ransom by technology. By this, I mean a business should not have to re-engineer itself to match the capabilities of the software being installed. The opposite should be true. And certainly, any migration to open source software should enhance flexibility by advancing the use of open standards, not the opposite.

Software migration should also enable and improve business processes, not hinder them. The technology must serve the business not the business the technology.

A certain amount of re-engineering for the sake of more open standards is to be expected, but not if the end result is less compatibility or a more closed environment.

People are perhaps the most challenging of the problems. No matter how good the software or how thorough the implementation process, ultimately it is staff that have to use the systems to perform their jobs.

Not being able to do so because of sudden and substantial change in systems will not only damage business flow, but also cause user distress and loss of productivity.

Naturally, there will always be some element of disruption in a software migration, but the goal needs to be to keep this to an absolute minimum.

So, how can this be done?

Don't install openoffice.org over the weekend and expect everyone to be happy.

Muggie van Staden is MD of Obsidian Systems.

Don't start on the desktop. Don't simply switch everyone's desktop over to Linux overnight. Don't install openoffice.org over the weekend and expect everyone to be happy. They won't be.

Do find the "easy wins". Technically, these may be complex changes in infrastructure, but the disruptions to end-users are likely to be minimal or even unnoticed.

Start, for example, with existing applications that can be migrated from proprietary Unix to Enterprise Linux or with database servers, or e-mail servers. Migrating current proprietary database infrastructure over to an alternative, such as EnterpriseDB, is a managed process that need not be rolled out to end-users until it has been proved to be working exactly as needed.

When everything is in place, the switchover can be done seamlessly. The majority of users have no interest in what database server is providing them with data. All they care about is that they receive the right data. And if they get that then they will be happy.

Or start with e-mail servers. Open source-based alternatives such as Zimbra provide all of the functionality, and more, of a proprietary system such as Exchange, but are open source. Users need not even know about the change to the e-mail infrastructure and can continue to work with e-mail as they always have. On the desktop they can use Windows and Outlook (if that is what they are used to) to check their e-mail as they always have.

Switching a key part of a company's infrastructure, such as e-mail, over to open source provides the benefits of open source software without entailing a daunting learning curve for end-users. It also lays the foundations for a future desktop migration, if that is the path decided on.

Migrating part of a company's infrastructure over to open source does not lock it in to migrating the desktop as well, unlike many proprietary systems, which try to steer the business down an end-to-end implementation. Open source software can be used where appropriate, and just as importantly, where the OSS alternative is better than the closed options.

Successful open source migration is also about matching implementations with the right users. The IT department is less likely to struggle with switching to a Linux desktop. The same is true of basic administration staff, such as secretaries and personal assistants. Switching the finance department or senior management over to an open source desktop when they need specific applications to perform their job will end badly.

Pilot projects are critical in preparing the way for an open source migration. Choosing the right pilot projects, with the right people, is just as important, as is finding an experienced vendor that has the right skills and knowledge to make migration as painless as possible.

Ultimately, bear this in mind: open source software is not an all-or-nothing proposition. There is still a lot to be gained from migrating a portion of business infrastructure over to open source. Companies don't have to be open source-only to start reaping the benefits of cost, flexibility and open standards.