Too often open source software is portrayed as an all-or-nothing option. In reality a mixed environment is the first step to a successful migration.

Free and open source software is famously versatile. Think of just about any piece of software your 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 of your 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 your business 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.

Processes

First processes. 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 that your business should not have to re-engineer itself to match the capabilities of the software you install. The opposite should be true. And certainly, any migration to open source software should enhance your flexibility by advancing the use of open standards, not the opposite.

Software migration should also enable and improve business process, 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

People is 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 do you do this?

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 application that can be migrated from proprietary Unix to Enterprise Linux or with your database servers, or email servers. Migrating your 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 is that they receive the right data. And if they get that then they will be happy.

Or start with email 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 email infrastructure and can continue to work with email as they always have. On the desktop they can use Windows and Outlook (if that is what they are used to) to check their email as they always have.

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

Migrating part of your infrastructure over to open source does not lock you into migrating the desktop as well, unlike many proprietary systems which try to steer your 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.

Matching people

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 who 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. You don’t have to be an open source-only business to start reaping the benefits of cost, flexibility and open standards.

READ NEXT

Muggie van Staden

Muggie van Staden

Muggie van Staden helped start Obsidian Systems while he was still studying at RAU. After completing his studies, Van Staden left Obsidian to work at an engineering firm, only to return in 1999 to take...

Leave a comment