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...
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseLinux.com
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.
