Ease Linux Migration By Asking Hard Questions First
by Kristin Shoemaker - Oct. 09, 2008Comments (2)- Related Blog Posts
- Over 50 Free, Must-Have Open Source Resources
- What Does a User Cost?
- Amarok Refreshed: Better, Stronger, Faster!
- Dell's Multimedia Mini PC Ships With Ubuntu
- What Lies Ahead for Chrome OS?
Over at TechRepublic, Jack Wallen details ten points to consider prior to moving your organization to Linux.
Some points are far more critical for operation than others (it is easier to switch to a more suitable desktop environment than make some highly specialized proprietary applications work with Linux, for instance), but all require attention. Depending on the workplace and industry, it might be worth an administrator's time to consider a few other points as well.
A few of Wallen's points need to be drawn out, first, because they are crucial for a successful migration. Any proprietary, mission-critical (non-browser based) applications designed for the former operating system must either be ported to the new system, be able to run (well, and reliably) through virtualization or emulation, or the system running these applications must remain in place.
Timing is, often, everything. If costly licenses were recently renewed for applications that will not be needed or will be replaced with open alternatives on the new system (Wallen mentions products with subscriptions, but this can apply to any recently purchased proprietary applications), it may be more cost effective put off the migration until these licenses have expired or the applications require upgrading.
Wallen mentions training -- specifically for IT staff. He also mentions searching out the more "Linux-adaptable" sections of the organization. These are very important points, though I'm not sure the "Linux-adaptable" aspect gets quite enough attention.
Training the IT staff is without a doubt important, as they are the first line of defense. Even if a problem should arise that is not platform specific -- for instance, an ethernet adapter goes bad -- the IT staff needs to have at least the knowledge to determine whether the problem is a bad component, or misconfigured software. It may be comforting (and a job perk) for the IT staff to work with an open source vendor that offers training and support services -- such as Red Hat, Novell, or Canonical.
The front-line, non-IT employees need special attention. They are not as interested (or not interested at all) in the technical aspects of the software they are using. It needs to work, and at least be somewhat familiar. Moreso, the new system should not be a surprise -- and merely annoucing that a change is in the works isn't enough. While OpenOffice and Microsoft Office deliver the same end result -- document creation and manipulation -- and the difference between them may really only be skin-deep, those working with these applications daily will notice differences, and the IT staff might encounter some real resistance.
The resistance might not be long-lived, but in my experience, it's always quite vocal. These employees just want to get their jobs done in the manner they are accustomed to, and they likely don't care about the benefits open source software is bringing the company -- these changes, however tiny, are slowing them down.
These concerns need to be heard. Better, they can be addressed before a new Linux deployment goes live. Whether it involves incremental changes to the existing system (gradually introducing cross-platform, open source alternatives to commonly used applications) or training sessions with computer and liveCDs to introduce employees to Linux, to hear their feedback and field their questions, end-user training is just as important to long term success as IT training.
There are important questions to consider before going forward with a Linux migration, and even when all is taken into account, expect surprises. Realistic answers to these questions -- and a realistic view of the migration and training/acclimation process -- will make the transition as painless as possible.
