In this installment of my two-part tip on Linux desktop migration, I'll show you some alternative desktop products and ways to handle the switch. In part one, I covered cultural issues and selecting user groups for migration.
OSS alternatives for the desktop
In some cases, there's an embarrassment of riches in open source software (OSS) alternatives for popular Windows applications. You don't have to weed through them all. A few have begun to gain wide acceptance and have been field-tested by many. They're well-known even to end users who are normally unfamiliar with open source apps.
- OpenOffice.org is the most-used alternative for Microsoft Office. This application suite has nearly all of the functionality of Office. As I said in part one, macro support leaves room for improvement. However, for any users who aren't using macros all day, OpenOffice will be able to serve as a drop-in replacement.
- Millions of people have replaced Microsoft Internet Explorer (IE) with Mozilla Firefox, not because they believe in OSS, but because it's a better and safer Web browser than IE. Firefox use has increased to the point where any self-respecting Web site can no longer afford to be IE-specific. Yet, a few are. Make sure that the sites used most frequently by your users don't require IE, and IE only.
- Mozilla Thunderbird is a good alternative for any POP3 or IMAP client, with more and better features than Microsoft Outlook Express.
- GAIM is a good cross-platform, instant-messaging client, capable of handling MSN, Yahoo, AOL, Novell's Groupwise and more.
- If you installed an OSS groupware product at the server-end of your network, it generally comes with whatever client it requires or can be accessed with a Web browser.
As a rule of thumb, OSS alternatives are available for most closed-source applications, as well as Linux versions of many commercial software products. It's important to keep in mind that OSS tries to offer functionality, rather than drop-in alternatives, for commercial applications. For example, GIMP is hardly a one-on-one replacement for Adobe Photoshop CS2. But in most cases, it does offer more-than-adequate image manipulation and processing features. OSS will do the job for you. However, don't expect it to offer exact replicas, or clones of commercial products.
Earlier in this series, I discussed methods and plans of action for a controlled migration of network services. The same principles apply to migrating user environments.
The preferred approach will depend on a number of factors, starting with the type of organization and the types of end users. You may also want to use different plans of action for different departments. A data entry pool may require other methods unlike general office staff.
A good way to start is by identifying user categories, as shown above, then forming one or more pilot groups. Ideally, a pilot group should contain a balanced mix of all user types found in our organization, or in the user category we want to address. Whatever the case may be, you should involve simple end users, skilled users, administrators and mobile users and so on.
Pay close attention to the human aspect of the migration right from the start. How do the members of our pilot group(s) view the changes that are about to be thrown at them? Are they apprehensive, reluctant or confident? Do they feel these changes will be worth the effort of adapting to the new environment? In other words, do they feel that the migration project will provide them with better IT services?
It is important to encourage all pilot group members to speak their minds about the proposed changes to their work environment. The success of any major IT operation should be measured not only in cost and quality of service, but also in user satisfaction. Remember that the primary role of IT in any organization is to support the users in performing the organization's core activities. Therefore, dissatisfied users are incompatible with the primary reason for IT services to exist.
While it is impossible to keep everyone completely happy, a proper assessment of and correct response to users' sentiments is mandatory. Responses could include briefings, training programs and easy-to-use support options throughout the entire project.
Should you encounter users who are firmly, or even aggressively, opposed to the proposed changes, it may be easier -- and may increase your chances of success -- not to include them in the pilot group for now. It may be better to treat such users on an individual basis, rather than as part of the pilot.
During the pilot project, changes should be introduced to the users gradually. One method of doing this would be to migrate desktop applications one-by-one, like replacing IE with Firefox. This demonstrates that things can still work properly after the proposed changes. Then, continue with the next application. The more features an application contains, and the more intensively these features are used, the more time a user might need to become familiar with the new software.
After users have worked with the fully-migrated application set for several weeks, the next logical step would be to migrate the operating system. If this is done properly, then users should experience little more than a minor change in appearances. Applications should still be started via the same desktop icons or or as similar a menu structure as possible. Otherwise, not much else should really have changed; using OOo or Firefox on Windows is pretty much the same as using it under Linux.
Carefully note all problems that may arise. There probably will be a few. Make sure you have an adequate solution for each of them before proceeding to the next step. Again, several weeks of use should be a reasonable period for all wrinkles to appear and to be ironed out.
Once you've got your pilot group(s) settled with the new desktops, gradually proceed with the migration throughout the rest of the organization.
Migrating an entire department all at once is not recommended. To maintain continuity, it would be better to migrate users in such a way that if something should go wrong with a given user environment, a colleague will still be able to perform the necessary tasks. For example, if you have three employees doing inventory management or accounting, don't migrate them all at once.
AftercareGiven the fact that all organizations are different, it is impossible to discuss the specifics of each migration. You will have to fill in numerous blanks yourself, depending on the needs of your particular organization.
Just as a one-size-fits-all manual is impossible, it's also difficult to plan for every eventuality and to anticipate every detail. Be prepared to encounter small problems -- such as a minor, infrequently-used but rather necessary application that somehow got overlooked during the planning stage -- and to find business processes that are impacted by the migration in ways that were not anticipated. These issues should be expected as a normal part of a migration, just like you would encounter similar issues while migrating from, say, Novell Netware to Microsoft Windows.
To the seasoned IT professional this should be nothing new. After all, IT management is an ongoing journey, not a destination. But having the best possible vehicle available can be a great benefit to the traveler, and OSS will prove to be an excellent vehicle for many parts of the journey.
Click here to go back to part 1 of this tip.
This was first published in October 2006