This article is excerpted from the book "The Practical Manager's Guide to Open Source".
How you plan timing for desktop migrations will depend on your policies. Do you typically replace desktops with your latest supported version of Windows only when the hardware needs to be replaced, or do you typically upgrade en masse on a regular schedule? For most organizations, the major factors in desktop migration will probably be hardware replacement and expansion from hiring. Keep in mind that if you purchased an enterprise-wide software agreement with an expiration date, then it will take over as the most important factor in your case. And don't overlook expansion due to hiring as a way to begin introducing open source on the desktop. New hires are less likely to resist, and existing employees will have the chance to see that the changes are not as great as they might have thought.
Third-party software, rather than the operating system, may also be the driving factor. A migration to open source may be warranted if it's time to upgrade or renew an expensive support contract for third party software, even if you did not plan changes to the hardware or operating system.
A worksheet to determine open source migration candidates
You can use worksheets to make an organized list of possible migration candidates, and a list of machines that are not suitable for migration at this time (untouchables). This will give you the information you need to determine what to test for possible migration feasibility. The spreadsheets are in Excel format (created in OpenOffice.org) to make listing easier, and to utilize formulas for return on investment when you get to the numbers later.
Step one: File and print servers
File and print servers are usually the easiest to transition to Linux. List each of these in your environment. I've started a list in the spreadsheet with typical examples; you can fill this in with your details. These are probably candidates for Linux, so unless you have something very unusual in your environment, put a "Yes" in the "Candidate for Linux" box.
Step two: Internet/intranet servers
Most Internet/intranet servers are good candidates for testing to find out if they would make good migration candidates. List each server that you have, along with the software you have running. Include everything -- that little Visual Basic application running on the intranet may force you to stick with Windows until you come up with a substitute. If you have written for a proprietary Web server, then the server will probably not be a candidate for Linux, but you should check with the software vendor. If you are using expensive hardware, it may be worth switching if the vendor has a Linux version (Oracle comes to mind, for example).
If you are running basic Internet services such as DNS, a firewall, or a proxy server, then there are clearly open source alternatives. Put a "Yes" in the "Candidate for Linux" column.
Step three: Mail servers
If the mail server is a basic POP or IMAP server, or Microsoft Exchange, then it is also a good candidate for a Linux migration. There are open source alternatives, so put a "yes" in the "Candidate for Linux" column. Even if you are running a different proprietary system, you may be able to migrate it for the next upgrade. Check with the vendor for its Linux plans.
Step four: VPNs
Don't forget your remote users. If you are running a PC-based VPN, you may be able to migrate this to open source. Again, put "Yes" in the "Candidate for Linux" column. (BSD, another open source Unix variant, is actually the preferred operating system for this task, since it works "out of the box.")
Step five: Other potential candidates
Next, list each application that resides on a server, and fill in the details. Look for other potential candidates within your environment, and leaving alone those that should not be migrated to open source. Remember that you are looking for practical solutions, not trying to force a fit.
For third-party applications that are platform-specific, it's worth doing a little research on their future plans. Ask about the client, too, if the application is platform-specific. You will need that information when you get to the desktop sheet.
For platform-specific applications developed in-house, you may want to hold off for a while until the next planned improvement to the system. If the client is also platform-specific, however, it may be worth thinking about how to convert to a Web-based solution. It will depend on whether you would otherwise be able to convert a significant number of desktops to Linux, thereby realizing a good deal of savings. For now, if a Linux conversion seems difficult, mark it "No." When we look at the desktops, you may find that it's worth another look if the client is a last holdout of platform-specific applications.
The question of whether there are open source alternatives for your applications will be a bit trickier, and it's best to hire a knowledgeable consultant to help you select software. You can do some research yourself to find alternatives, but be sure that anything you find is production-ready. You may find information from industry groups relevant to your organization.
Once you have a complete list of your server-side applications, you will have a count of the candidates for testing to determine Linux migration feasibility.
As an open source business analyst, Maria Winslow assists clients in understanding the technical and budgetary impact open source software will have on their computing environments. She is a frequent speaker and author on the topic of open source, and is a contributing editor of open source applications at LinuxPlanet and Linux Today.