Problem solve Get help with specific problems with your technologies, process and projects.

How to switch an enterprise to OSS, part two

Learn the right way how to plan for worst-case scenarios, assessing system inventories and rollouts when you migrate your commercial software to OSS in a corporate environment.

Taking an enterprise out of the closed-source software deadlock into the less costly and more flexible world of open source software (OSS) is heady stuff. This series on migrating an enterprise to OSS is designed to help your project team keeps its collective head together during the process.

So, in part one, we got our assets straightened out in a comprehensive inventory of the server room. Now, it's time to make a list of which products we need to install, the order for replacing old products, what we already have available and what other tasks to perform.

Such a list might look like this:

Service Implementation
Server OS Install suitable Linux distribution
IP address management Install and configure DHCP server
Name Resolution Install and configure DNS server
Time synchronization Synchronize with external NTP server, Install internal NTP server if needed
Directory services Install and configure OpenLDAP, Migrate Exchange data, AD, NDS or domains to OpenLDAP
Authentication services Add Samba authentication to OpenLDAP, Migrate authentication services (requires new passwords)
File services Install and configure Samba, assign volumes, migrate data to new volumes or re-map existing ones to Samba
Print services Install CUPS, configure it to work with Samba
Messaging services: MTA Install Courier MTA
Messaging services: Mailstore Install Courier IMAP
Messaging services: webmail Install Squirrel Mail
Spam Protection: Provided by Internet Service Provider
E-mail virus protection: Install Amavis with (commercial) McAfee
Groupware services: To be investigated
Shared agenda: To be investigated
Web services: intranet Install Apache, MySQL and PHP
Web services: Proxy Install Squid
ASP back-end services: Requires IIS, leave unchanged

This list is your starting point, and it should be supplemented with diagrams, topology overviews and other charts.

Of course, this isn't an exhaustive list of OSS products you could use as replacements for commercial ones. There are many options.

Unfortunately, you may encounter proprietary systems or services that cannot be replaced with OSS products. Financial applications that require Microsoft's Internet Information Services (IIS) or a back end that needs Windows Server with the .NET framework are good examples.

Potential pitfalls and complications

In my opinion, a worst-case scenario list is a must for any migration plan. Make a list of all factors that could possibly interfere with a smooth migration. This is no time for denial!

In making your worst-case scenario list, don't focus only on products and systems. People problems derail projects more often that product problems, from my experience. Here are just a few contingencies that your team should consider:

  • What if certain members of your IT staff are forced to go on sick leave halfway during a critical phase of the process?
  • Do all key roles in the process have at least one backup person who is aware of the current state of events at all times?

    If the project depends on third parties for contract work or support, will there be a holiday period during which these companies close?

  • Are there any unspoken or unaddressed concerns within your project team? Staff members who feel uncomfortable about the way things are being planned or controlled may find it difficult at a later stage to deal with the pressure of this critical operation.

Each step of the process should have a proper back-out scenario. If the newly installed service does not work properly upon deployment, a rollback to the old situation must be an option, so that business can continue while the problem is being solved.

Testing and pilot projects

A test environment is essential. Testing should be fully planned and must be conducted before the first OSS component is rolled out into the production environment.

Plan your tests in an early stage of the operation. This will give you enough time to consider the matter properly and to deal with complications when they arise. It pays to conduct a test migration one or two weeks before the actual migration.

Test environments may be small scale, as long as the planned systems can be give sufficient performance under a production load. Be it large or small, however, the test environment must implement all services, so that their correct functioning and interoperability can be assessed.

A successful test should be followed by a pilot project, in which a small number of end users from all affected parts of the organization work with the new systems in a production situation. The pilot presents a good opportunity to assess the effectiveness of user training and awareness programs. If users feel uncomfortable with the new environment, they may need further briefing before being exposed to the new work environment.

The pilot should start when all IT staff members agree that the new services offered are ready, and should continue until the end users agree that they're ready.


Replacing the old IT infrastructure with a new one is typically not done overnight. Most organizations prefer to implement components one by one, as far as possible. A rollout per department or location -- if multiple locations are involved -- may be preferable as well.

For some services the changeover may be relatively simple. For example, when a file server has been properly configured, it may indeed replace the old system overnight and the end users may not even be aware of the change. In other cases, a "shadow" configuration may be desired, where a critical service is rolled out while the old one remains live, and users are gradually moved from the old to the new system. Then, only when everything works perfectly, and everyone uses the new system, the old system can be decommissioned.

If large amounts of data are to be migrated from a live system, it may be possible to configure the new system to mirror the old one. Once replication is complete, a simple change in DNS records may be enough to make the actual changeover to the new system. Or, it might be possible to remap server volumes from the old to the new service.

The actual changeover is the moment that will have the greatest impact on end users. Once again, make sure that user training has been completed and that sufficient helpdesk staff is on hand to deal with peaks in support calls.

Dig Deeper on Linux servers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.