Step 5: Moving on to the actual migration, the paper wisely recommends identifying a cross-function group of "technology leaders" -- employees with a knack for using the company's systems and to whom peers already turn for advice and help about using their computers. These people will be drawn from all levels and functions in the company. They will serve as vanguards for change, as communicators and advocates for the benefits of migration, and they will need to be rewarded appropriately with recognition, status, and perhaps practical incentives. They should be given access to the company's decision makers and together form the action team for the migration.
Step 6: At this stage, the paper recommends a comprehensive training course for all staff. Offering training is critical; omitting it was a key cause of the failure in Freiburg. My own experience suggests not all staff need the same training. A tiered approach -- with basic, advanced, and online training all available for different groups -- is more appropriate and less costly. Whichever strategy you prefer, investing in training is a critical success factor.
Step 7: While all this is happening, capture everyone's observations and questions in a comprehensive FAQ. A shared memory of the experience is an important factor in the success of a migration.
Step 8: While you may have assumed that open source means cutting costs, particularly in regard to "support," nothing could be further from the truth. Take the money you would have spent on licenses and invest it in professional support. You may well have your own user-facing (level one) and technology-facing (level two) support in-house, but it is important to invest in access to third-level support as well. When you do this, you also invest in the open source community and guarantee the longevity of the code you're migrating to. Unique among open source projects, the Document Foundation is devising a certification scheme to help you identify third-level support organizations.
Step 9: A critical success factor you may not have otherwise considered is the staff who are not migrating. Your survey from step one will have identified a small population of staff who will have strong business reasons to stick with Microsoft Office. Those people also need training and support in their roles and responsibilities in the new environment. They need to respect the interoperability priorities of the company, stick with standard fonts, and use ODF and PDF to communicate with others. Microsoft Office supports ODF too.
Step 10: Finally, a focused, cross-company communications strategy is needed for the migration. The paper includes a full sample messaging schedule. Surprisingly, it doesn't highlight one of the easy wins of a migration to open source: Your staff are free to take the software home and use it on their own PCs and Macs, and to give it to the whole family if they want.
The growing importance of the open Web and interoperability underscores the relevance of this week's Document Freedom Day celebrations. The Document Foundation's white paper is a useful tool that may just make the difference for your company in migrating to open formats and open source tools. It deserves serious consideration. What company can afford to be locked in to any single vendor strategy any more, even for office tools?
This article, "LibreOffice on every desk: A 10-step plan," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.