Some companies consider it too difficult to switch desktops. That's not necessarily so, and it is absolutely possible to succeed in a well-planned move off of the Microsoft platform.
I'm dividing this tip into two parts. The first half explores cultural issues and selecting user groups for initial migrations. In the second installment, I examine alternative desktop products and offer some step-by-step instructions.
The human factor
You may get away with migrating file and print services from Linux without your end users being aware of it. On the desktop, you will not have that luxury.
The human factor is one significant difference between migrating server and desktop environments. End users often think that their immediate work environment is a personal space. They are wary when you propose changes that they will experience directly and immediately.
Many users find changes to their desktop environment confusing, annoying or even intimidating. They generally prefer to keep whatever they're accustomed to. Something as simple as a moved menu option may generate a flood of helpdesk calls and complaints to non-IT managers.
The best way to prevent this is to pay close attention to the end users' needs and preferences throughout the entire migration process. Be sure to brief and train them before the actual changes take place. Extensive support before, during and after the migration, as well as making sure that the end users realize that adequate assistance will be available at all times, are key factors to maintaining the tranquility index.
To migrate or not to migrate?
Should you really try to migrate all desktop environments? Well, probably not. Not all user environments are created equal. The requirements of a user who is mainly involved with data entry or word processing are totally different from those of a CAD engineer or a financial administrator.
Dividing users into categories is a good way to start. Depending on the type of organization you're dealing with, you could have, for example:
- single-application users (e.g. data entry)
- general users (e.g. administrative or office staff)
- specialized users (e.g. developers or call center staff)
- power users (e.g. researchers or developers)
- mobile or remote users (e.g. sales reps or telecommuters)
- technical staff (e.g. systems or network administrators)
Obviously, the easiest users to migrate are single-application users for whom a suitable OSS replacement application is available. At the other end of the spectrum, we find users who rely on a specific major application -- or a whole range of smaller ones -- for which there is no good OSS alternative.
Strategies like virtualization and emulation may help you work around some user issues. For example, an architect's office in Johannesburg, South Africa, currently runs AutoCAD on Linux. Even so, virtualization and emulation have limitations, and you can expect no guarantees about stability or performance.
The easy part
Fortunately, the largest user group will often consist of single-application users and all-around users. This group usually relies on office suites, email and Web browsers. Often, the office suite is Microsoft Office. This entire package can be replaced quite easily with OSS alternatives, like Linux, OpenOffice, Firefox and Thunderbird.
Email could pose your biggest problem, since it is mission-critical. Migrating off of the Microsoft Outlook email client isn't as daunting as it once was, because good alternatives now exist. (See the previous installment in this series for OSS groupware alternatives.)
Be aware that even "easy-to-migrate" users may encounter limitations with their new desktops. Not all Web-based applications --electronic banking software or business-to-business applications -- will work correctly with Web browsers other than Microsoft Internet Explorer.
Microsoft Office users who rely heavily on macros will find that many of their macros no longer work in OpenOffice. This situation is improving constantly, but seamless replacement cannot be guaranteed. If large numbers of users are involved, rewriting macros may be an investment worth considering. But even then, macros obtained from third parties, forms obtained from vendors or clients for example, may remain a point of concern.
Migrating technical staff should be rather painless, as well. Systems and network administrators normally have no difficulty in learning to use a new desktop, and many of them should already do the bulk of their work in an SSH window and a Seb browser anyway. Novell administrators have a Linux version of ConsoleOne available, and rdesktop provides an open source RDP client for the administration of any legacy Windows platforms left in the server room.
...and the difficult part
If all users would employ standard applications on standard desktops, life would be a breeze. Standardization has tried to achieve just that in many organizations. But in real life, there are often exceptions like locally installed, non-standard applications, or users who do other things than just standard office work. This is where things can get a bit challenging.
Several workarounds present themselves.
- You could make use of virtual machines or emulation (e.g. VMware or, to a certain degree, Wine).
- You could deploy a Citrix-based application server and let the Windows-bound applications run on that platform with a Linux client on the desktop.
- As a last resort, consider dual-boot configurations.
But all of these workarounds can be cumbersome, unreliable and/or slow. This eventually translates into lost productivity and an increased support load, which is the opposite of what we wanted to accomplish with a migration to OSS.
Frequently, the best solution is to leave these desktops alone. By all means, let's be pragmatic. If a user can be more productive on Windows than Linux, or there are specific cases that are difficult to standardize anyway, there's no real point in trying to switch to Linux. Just migrate as many applications as possible to OSS versions that run on Windows, since this will help to reduce licensing costs and may make a future migration easier.
Only in very specific cases should Citrix, VMware or Wine be considered. For instance, use one of them when only a small number of key applications on a few workstations stand between you and a corporate-wide desktop standard.
In part two, I'll discuss some open source desktop applications that can stand in for Microsoft apps. Then, I'll offer some step-by-step deployment tips.
This was first published in October 2006