Migrating to OpenOffice: a small roadmap
Talking OpenOffice

During a substantial part of 2003 I was involved in implementation and deployment of OpenOffice at organisations which are stylised as SMEs (small and medium enterprises) and a few public libraries. The varied experience sets obtained are perhaps a roadmap towards deploying Free/Libre Open Source solutions commercially. A 5 day GNU-Linux workshop held at the Indian Institute of Port Management during the month of November 2003 also provided an insight into how the government sector approaches F/L OSS and more specifically Office suite migration.

Making a case for OpenOffice migration from Microsoft technology based office suites calls for tact, delicacy and understanding of the situation-at-hand. Most enterprises in the SME segment have a very clear mandate on IT budgets and this generally leaves little room for error. Also toss in a healthy dose of fear factor related to data loss and loss in productivity and you end up with a potent concoction.

This text would perhaps be best suited if it is transformed into a collaborative project - a sort of 'open ended book creation'. Would a wiki format be then the ideal option ? Probably so. This time around I am keen on putting to paper the immediate problems. Perhaps at some later stage we might even think of extending the reach and scope of this text. A caveat is however needed. The issues raised are the ones I repeatedly stumble across, there are others and I do plan to address them soon enough.

Issue # 1 : Err...what about the 'support' ?

Talking about F/L OSS implementations at the proposal stage inevitably leads to this question. Not really surprising if one considers the fact that most SMEs are avid users of unlicensed versions of MS-Office. And for them support is one of the core areas of concern.

Here the company/consultant involved in the migration process needs to provide re-assurance that technical support is community based as well as a responsibility of the company/consultant. Providing case studies of Indian companies who have shifted to OpenOffice or are publicly talking about such migration would help augment the case. The 'Users' list at OpenOffice as well as the Issue list for tracking bugs are useful in addressing typical situations. However, if the target base company is not into IT (ie it uses IT as a facilitator) do not please suggest the mailing list option.

Issue # 2 : Are we looking at a logistical nightmare when migrating to OpenOffice ?

Every migration path has its own unique hassles and OpenOffice migration is no exception to the rule. An SME setup (or come to think of it - any organisation), over a period of time, lands up with a myriad format of documents. With usage of unlicensed software being rampant, it is not strange to see multiple wordprocessing suites being used to create documents. In such a case it is better to begin small. A look at the OpenOffice site reveals the support status for the current stable build. Tracking the document format issues through the mailing list also enables a lot of queries to be answered.

The thumb rule is then to begin small. The best option is to take a sample of all existing document formats in the Company and estimate the possibility of converting them to OpenOffice format. It is worthwhile to provide a complete and clear picture about the possible loss in format to be expected during the migration.

OpenOffice does have a problem with certain bullets, paragraph settings and it is best to provide an acceptable workaround. It is suggested that if the migration path is from Microsoft Office to OpenOffice, then it is best to use 'Styles' to bring about the conversion - more often than not this is the safest bet.

Issue # 3 : But won't we have to undergo extensive retraining ?

Creating cost centres in retraining and 'unlearning' is something all organisations are loathe to indulge in. Presenting a case for migrating to OpenOffice will bring this issue up and it is best to tackle this upfront.

I have personally found that office suites do favor a generic interface. This has an immediate upside that the familiarisation is initiated with some lead. The best part of training users in OpenOffice is to allow them to learn on their own. Something which I tend to call 'guided self-discovery tour'. It is also good to address the training workshops from the perspective of the end-users. Allowing them to develop their competence in OpenOffice through iterative and interactive sessions provides a level of confidence. Do ensure that the participants in the workshops receive printed assignments, study-notes and tips and tricks aimed at power users. Nothing motivates more than a properly done documentation aimed at providing a comfort factor.

Issue # 4 : 'Do we really have to shift from our existing platform ?'

This is really a question that seems to crop up every now and then during the migration process. The best way to deal with this is 2-fold:

[1] identify and encourage active users of OpenOffice during the workshops. These people are the bright sparks who are motivated, committed and willing to learn. And then project them as champions in your argument.

[2] make a case towards financial benefits of the migration and then slowly ease out the existing platform to make sure that OpenOffice is the suite of choice.

Note that in each case, management support and 'project sponsorship' is vital and thus closer interaction with the management is suggested.

Thus, to sum everything up - migration to OpenOffice is an interactive process involving Participatory Approach. Taking the users through an install of the suite (this is relevant in cases where the IT department is in charge of someone who does double duty as something else), talking about problems and addressing issues, presenting case studies during workshops motivates participants. Providing a compilation of links and URLs related to issues themed around OpenOffice along with OpenOffice books helps to clear up a lot of confusion. Demonstrations that are focussed and aimed at the different user segments clearly showing the interoperability of OpenOffice with other office suites along with projected savings help convince the management to consider a migration policy. Lastly, take small bites at a time. Once these fall into place, the bigger migrations become a piece of cake.

Sankarshan Mukhopadhyay is a Free Software enthusiast and a member of the Ankur Bangla Project. His blog Random Thoughts is about the human aspects of F/L OSS implementation. He can be contacted at sankarshan at softhome dot net

Copyleft 2004: This document can be reproduced in entirety with due credit to the author.
- posted by sankarshan @ 2/21/2004 04:51:00 PM 0 comments