How to switch an enterprise to OSS, part one

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.

Migration planning 101

Turning a corporate IT environment upside down is obviously not something to be undertaken lightly. A thorough inventory, an overview of possible pitfalls, and detailed plans of action are essential.  

A migration will affect business processes, as a one-to-one replacement of any software system with another one is not always possible. Don't underestimate the business process aspect of the implementation. In particular, include end users who take part in those processes to join your planning team. Effective end user evangelism and training are critical to successful migrations.  

Schedule a plan evaluation period before anything is done at all. Things that may have been overlooked during a planning meeting often have a habit of surfacing during informal discussions around the coffee machine.  

Did I say that user buy-in and training are important? It bears repeating!

The stories I read about businesses that have migrated to open source software (OSS) successfully always tell the beginning and end and leave out the middle. Generally, they describe why the company chose OSS and how well OSS performs in production. If you're like me, you wonder what kind of pain and anguish they went through to get from point A to point C.

That's why I'm starting at point B in this series of tips. I'll discuss, in broad lines, how to migrate from closed/commercial software to OSS in a corporate environment.

In this two-part tip, I cover migration planning, system inventories, worst-case scenario preparation and rollouts. Following installments will cover:

  • An in-depth look at migrating directory services and/or Windows NT domains to OpenLDAP;
  • Linux-based alternatives to services (e.g. file and print services, messaging, groupware and ERP software); and,
  • Migrating desktop environments to OSS.

Making a systems inventory

Few things are as permanent as a temporary fix, especially in IT. Systems are deployed, and services are added to them on a regular and often ad-hoc basis. At the end of the day, it's not always clear how all these services are interdependent. In fact, often those interdependencies only become clear when critical services go down.

In order to prevent unpleasant surprises during a migration, a clear insight in what goes on with each system and server, and how all components inter-relate, is essential. Of course, this is an excellent time to consider what a component should ideally do and not do, and what it actually does at this moment.

Depending on how your IT department works, you may find yourself dealing with the after-effects of ad-hoc management more than you expected, before the migration can begin.

A systems inventory can be fairly simple. In fact, in a properly managed IT environment, you should already have one. It should list essential details. Here's a very simplistic example:

System name: Server 1
System hardware: Pentium IV, 2.4GHz, 1024MB RAM, 5x120GB RAID-5 on Promise FastTrak100LP RAID controller, 2 x 3Com 3c905 NIC
OS: Windows Server 2003
Clustered: No
Connected to: APC Smart-UPS 700, 3Com SuperStack-3 Ethernet switch

Any network or systems administrator who's on the ball should know which relevant details apply to his or her network. The important thing here is to minimize the chance of details being overlooked.

Next, compare the systems inventory with the hardware requirements of the new software that will run on this system. For example, if we want to run Linux on the above server, does the intended version of Linux properly support the RAID controller? And can it talk to the serial interface on the UPS? If not, is it worth the cost and effort to replace the unsupported components, or would it instead be better to change our deployment plans and use this hardware for other purposes?

A similar inventory should be made of all services. As an example, we could list the following:

Service: File/Print services
Runs on: Server 1
Software used: Windows Server 2003
Department(s) served: All
Service requires specific hardware: No
Service: SQL Database Server
Runs on: Server 2
Software used: MS-SQL Server 2000
Department(s) served: Sales, purchasing, warehouse
Service requires specific hardware: Yes: RAID-5 array

Looking at this example, it should be obvious that file-and-print services may easily moved to any platform that can do a similar job, but since it serves the entire company we need sufficient performance and disk capacity. A large number of users will potentially be affected if the service becomes unavailable, but it depends on how the users work with this service in order to estimate user impact if it goes down.

The database service, on the other hand, is critical enough to require a certain amount of redundancy and reliability (hence the RAID-5 array). It may not be moved to any old hard disk. Performance-wise we may or may not need much capacity, but availability may not be compromised.

So, we've made a good start. Let's get going with the fun part, making a schedule for deploying some shiny new OSS products. That's coming in part two, along with some warnings about potential pitfalls and complications.

Continue to part two.

This was first published in March 2006

Dig deeper on Enterprise applications for Linux

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchDataCenter

SearchServerVirtualization

SearchCloudComputing

SearchEnterpriseDesktop

Close