Saturday, June 26, 2010

Moving to Linux

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 inventory

The 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 formats

If 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 applications

People 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 applications

Your 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. Protocols

Do 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 adopters

Once 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?


  1. ping:

  2. You covered the technical aspects pretty well. I would make sure you have hired a Oo specialist that knows macro conversions backwards and forwards. Forgetting that little Chihuahua can ankle bite you to death.

    Your early adopters component.

    I tend to disagree. I don't care that you can find cross platform apps for both OS's. There are sufficient differences even at the app level that will drive support and their costs nuts. You need to move as fast as possible to move the user community to the new platform as fast and efficient as possible. For example. If you move to OOfice off MSOffice you would NOT move to individual copies of the software. You would want to move to the OO network variant if you can and have the server in place to support it. Single chicken to support and maintain.

    As to the early adopters. Well ok but I think you miss a better opportunity. There that class of user in every sub org that is the alpha techno nerd. No they don't work for IT, but they have the skill set equal to that of an IT person and passion to match. THAT is who you tap as the early adopter. Involve them early, make them part of the transition team and they will become your support arm within that group.

    Just my opinion.

  3. "Note that OpenOffice can read and write all of these formats."

    In theory. In practice, you're likely to run into problems with botched document formatting.

  4. Anonymous, I've had far, far fewer problems using OO to read MS than in having MS read itself. Far. Way far.

  5. I've successfully moved my school (K12) to GNU/Linux. Free software truly is better. The pros definitely outweigh the cons. Yes, we had rough times, but 99 percent was PERCEPTION, not founded in proven issues with the software or hardware. Only the laggard, poorly skilled and ignorant teachers who refused to change had the hardest time, and they could only muster the perception argument that "Its different..."

  6. This is an excellent article, and with enough project management-y detail that it should be helpful to most techs trying to switch their company to Linux.

    I think it's important to balance the early adopters with spped of conversion. If yuo take too long you'll lose the momentum you were talking about in your article. Better to keep the schedule tight and keep things moving.

  7. Don't overlook migrating to thin clients as a good way to go. Then there is minimal software on the clients and you have fewer software instances to manage on servers. You get the added benefit of the performance of a newer server in place of the performance of an old client. Every perceived performance increase is one less perception of change. Folks resist change unless the result of change is obviously better. In my present shop we had XP machines taking minutes to boot and log-in to a usable desktop. The thin clients can boot in 30s and login is 2s. We got that performance by buying a few new PCs to use as terminal servers and use the same old machines as thin clients. The users see huge increase in login speed. Same with opening applications. The new machine does it faster and the users see speed on the clients because their apps run on the new machine.

    I use Debian GNU/Linux and run apt-cacher-ng on a server so I can install from bare metal in a few minutes because the packages are all cached on our server. I can also do imaged installations using CloneZilla. Folks like it when the changeover is fast. Many PCs can be made thin clients just by setting the BIOS to boot PXE.

    New monitors, keyboards and mice help any changeover.

  8. Robert, thin clients are definitely a good option to keep open. But I hadn't thought of re-using old PCs for the clients - previously, I'd helped departments set up thin clients that were separate (and inexpensive) appliances.

  9. Similar to thin clients are virtual desktops. We're starting to see more of this in industry, as well. Going virtual also means your users can access the same desktop from home if they use remote access. Except the business logic remains at the office, and there are no work laptops to worry about getting lost.

  10. Heh, that and how Office introduces subtle formatting changes based on what printer you have attached, vs the person who created the document. I've seen this a few times at work, although rarely.

    Sometimes it's jsut a word that gets pushed to the next page. But occasionally that word is enough to kick in widow/orphan protection, and the first 2 lines of a paragraph gets moved to the next page.

  11. Thank you for the great post. I work everyday to migrate users over to open source solutions, and incorporate many of the strategies you have mentioned. I also have learned some new ones to use in my future deployments and to share with my partners as well.
    Other comments focus on the OO formatting issues, which I have encountered with Presentation/PowerPoint, overall, the relief of stability and security usually outweighs the re-formatting issue.

  12. Thank you very much for that marvelous article

  13. @ JH,

    Great article! I kind of lol'd halfway, and had to think what sort of undertaking it would be to get one of the places I worked at to switch over to Linux. I don't have enough pull to make it work, so I never attempted, sadly.

    Anyhow. I just wanted to comment on MS and standards. Does anything really need to be said?

    Why does MS keep using formats/protocols that stray from anything standardly accepted in the industry? Simple.
    1. You have mass market penetration. You are the gorilla (through superior marketing, no less) in the field.
    2. Because of aforementioned fact, now you have ability to use your 'name' whether it's reputable or not (and generally the mentality is, 'well, it is widely accepted, and thusly must be reputable') to push new products. Just like vendor-lock-in, users are using a product that is commonly seen, but does not play nicely. However, because there is such mass use of said product, that any alternative immediately looks inferior because the ALTERNATIVE SEEMS TO NOT PLAY NICE with the offered product.
    3. ????
    4. Profit!

    Oh I had a laugh. Why all the longwindedness you might ask? Simple: This is an MS tactic that proved effective to them, up until the point that they shot themselves in the foot.

    I've made a document using OpenOffice, saved in .doc format (My resume). I later opened it with Office 2003, and it appeared perfectly as it was created in OpenOffice. I later open it in Office 2007, and everything was askew. After scratching my head... I thought to myself 'Well, hell. Maybe OpenOffice just isn't there yet'. I re-typed, verbatim (no page breaks, or the like) my resume in 2003. I again, opened it in 2007 (Mainly, because I want my document to be seen by all potential employers as it should be, and they might run 2003 or 2007, or OO) and everything is botched. The formatting is askew.

    Yes. Non-standard formatting has played into the hands of MS... Made everyone else look inferior... And now they have issues between 2007 and 2003.

    Conclusion: OpenOffice has better compatibility for 2003 documents (creating/reading/editing) than 2007 ever has (I re-tested this last week, and I lol'd).


  14. I, of course, a newcomer to this blog, but the author does not agree


Note: Only a member of this blog may post a comment.