Several organizations have been successful in
moving to Linux. I'd like to discuss this topic again.
How do you move an organization to Linux? What's the process? It's not as simple as coming in over the weekend, re-installing everyone's desktops with the latest Linux distro, and hoping things go for the best. You need a real transition plan, a strategy to move the organization.
Here's what I would do to ease a transition to Linux:
1. Take an inventoryThe first step in any transition is to understand what you're working with, and what your obstacles might be. The key here is to be brutally honest. Why is the organization running Windows? Are there applications that are
only available for Windows? Do any of your "power users" require obscure features in, say, Microsoft Office to do their job? Maybe your users need to work with an outside web application (perhaps a vendor web site) that requires IE.
Is your hardware Linux-compatible? In my experience, wireless network cards and high-end video cards are the areas that tend to cause problems. You should also check your printers to make sure that Linux can drive them (typically, HP laser printers and any Postscript printers work fine, but many Canon desktop inkjet printers will not work.) If you find anything that's not 100% compatible, look for workarounds. For example, you may consider the Nouveau driver for NVIDIA cards.
Also understand your budget. Will you need to purchase new software for Linux that replicates features and functionality from the Microsoft platform? And how much budget is available to you to cover migration costs?
Most importantly, understand
why you are moving to Linux. For many organizations, cost is the #1 driver. It's expensive to run a Windows environment, moreso if you also run Microsoft applications on the back-office (think MS Exchange and MS SQL Server.) Why are you making the move? If you don't have a good answer to this, you're going to have an uphill struggle the rest of the way.
2. File formatsIf everyone in your organization creates Word documents in DOC format, and Excel spreadsheets in XLS, then consider yourself lucky. But Microsoft has since introduced DOCX and XLSX as their "Office OpenXML" format. Your organization will likely have a mix of these file extensions floating around. Note that OpenOffice can read and write all of these formats.
Look at what other files your organization produces and consumes. Can Linux work with them all? What applications read and write them? This may have been covered in step #1, but match them up anyway.
Where possible, define a standard for your users that happens to work well with Linux. The obvious choice is ODF: the OpenDocument Format. Microsoft Office 2010 or Office 2007 SP2 can read/write ODF files, as can OpenOffice.
But, as is the case when making any change, you should be sure to test a reasonable sample of
real files from your organization to ensure that nothing is lost (for example, special formatting?) if you save the document in ODF format.
3. Web applicationsPeople sometimes forget this option. Do you have applications that can run via the web? Maybe you have a group calendar system that also has a "web client". This can be an easy way to remove an obstacle to your Linux migration. If you have any applications that are "Windows only", check if there is a web option available to you.
In my case, when I first
ran Linux at work in my current organization, our groupware application was advertised as "Windows-only". But I found the web version worked perfectly on Linux using Firefox, so I got along fine.
As in #2, be sure to test that the web application does everything that the desktop version can do - or at least, that it covers all the functionality that your users will need. I'll assume you'll test again at each of the steps below.
4. Desktop applicationsYour users haven't moved to Linux yet, so everyone is still running Windows. To help with the future migration, start moving your desktop applications to versions that also run on Linux. For example, replace Microsoft Office with OpenOffice for Windows. Make sure Firefox is installed on everyone's PC, and that your users know to use it.
Moving your applications now means your users have time to become familiar with the new environment - while having that "buffer" of still running on Windows. And it reduces the anxiety that may develop when you eventually migrate your users to Linux.
5. ProtocolsDo you have any Microsoft-specific protocols running on your network? Are you running Active Directory? Microsoft Exchange or Novell GroupWise? The thing to look for at this stage is that Linux can talk to all your back-office applications.
Note that GNOME Evolution includes support for Exchange 2000/2003 and GroupWise. And Linux can talk to an Active Directory network, but you may be unable to manage profiles on Linux through AD.
6. Early adoptersOnce you have set up your users to use web applications and open desktop applications, it's finally time to start migrating users to the Linux platform. But don't expect to move everyone at once.
In making a major transition like this, I have found it easier to move groups of people at a time. There's no sense in migrating everyone at once. After all, they're all using the same applications now, so you don't have to worry about cross-compatibility. Your biggest worry at this point should be
adoption and
acceptance.
Pick a smallish group of users, but one that's self-contained. Ideally, the people in this group should already be excited to make the switch - these are your early adopters, and who (if you do things right) will soon become your allies. Maybe this is your server support team, or your database administrators, or some other "technical" team.
Do training with your users, and set expectations appropriately. Show lots of screenshots of the Linux desktop, give a live demo of running Linux on your own system. This takes the "fear" out of doing a move, by seeing that Linux looks and works just like Windows. Be careful about showing off too many "geeky" things - stick to the functionality that your users will find familiar, and introduce only
a few new features like virtual desktops. In particular, avoid showing off the desktop effects - your users may not find "wobbly windows" or "workspaces on a cube" as impressive as you do.
Agree to a migration schedule with these users, and make sure their migration is
flawless. You don't want any hiccups with your very first migration, so make sure all your bases are covered.
Plan ahead for problems and workarounds. You might dual-boot their laptops or workstations, so they have a quick and easy way to boot back to Windows if they run into problems on Linux.
Stay visible to your early adopters, and respond to questions or concerns right away. There is no such thing as "too much communication" at this stage. Hang around their offices, if you can, so you are immediately available if people have issues.
If all goes well, this group of early adopters will become your allies in future migrations. When things have settled down, meet with the next group you want to move, and repeat. Encourage your early adopters to share their experiences, good and bad. As you continue to have success with each group, your momentum will increase, and you will find much less resistance from the rest of your organization in migrating to Linux.
Finally, in doing your migration, you can't forget your desktop support. Previous to this, all your support staff have been trained in managing Windows desktops. Supporting a Linux environment will be different for them. Train your desktop support staff to run Linux. If you deploy new systems by installing an image, make sure you have a Linux image available to use.
Above all, be realistic with expectations. Not just managing what your users will think of using Linux, but in how quickly you can move people to a new platform. My advice is to take the time you need in preparing, so steps #1-5 should take the longest. And give your early adopters in #6 time to adjust, as well. Don't give users an excuse to complain that you are forcing this migration; let each step take the time it needs.
That's my experience, anyway. How would
you manage a Linux migration?
