Migrating to ODF
Historically, many organisations aimed to "standardise" on one version of a single product, within a managed environment. In those terms, the term 'migration' really meant 'product migration', and "standardise" merely meant "product self-compatibility". Nevertheless, changing formats and changing software cause reoccurring work.
Now a migration to ODF means adopting an actual technical standard, not focussing on a single product. This is a different approach with as a results a stable and consistent work with documents in the nearby and far future.
The use of standards makes a wider variety of tools available to optimise for different tasks and environments. This allows the user to choose 'best of breed' solutions, while remaining interoperable. The fact that you introduce diversity and specialisation in your IT tooling, makes 'migration' perhaps too limited a term, but we'll stick to it for now.
Depending on the infrastructure, the users needs and the dependency on certain software that does not adequately support ODF 1.3, more or less effort will be asked by the migration.
There is a variety of solutions available that work with ODF 1.3 out of the box.
For other existing applications the behaviour may have to be changed by means of:
- preprocessing (converting to ODF 1.3 before data enters the application)
- a plugin, add-on or extension to enable handling ODF inside the application
- post-processing (when data leaves the application, adjust or convert to proper ODF 1.3)
In this chapter, we advise on the migration to ODF in general. If deployment of new software is involved, we refer to detailed migration guides available for specific paths, such as from Microsoft Office to LibreOffice or Apache OpenOffice, or very concise ones (such as the migration from Lotus Symphony to Apache OpenOffice, as these products have been merged) and to consultants experienced in this kind of migrations.
Don't forget what other benefits of a migration to ODF can be important, when designing the details of the migration. Those were probably considered when the decision to migrate to ODF was made:
- Improved functionality and innovation
- Better integration
- Increased flexibility
- Security, confidentiality and privacy
- Strengthening the local economy
- Technical self-determination
- Cost reduction
Organisations all over the world have successfully moved towards ODF for similar reasons - your organisation too can do it!
Different aspects of the migration
Look at what you need and what the extras are
When you switch to new software, try to determine whether it contains all the features that are needed. But also whether there is any additional functionality that will be useful.
People within the organisation who love nothing better than "playing" with software the whole day may be involved in spending time on the applications that you have selected. They will often discover interesting new ways to use the software and will help to create a positive culture around the new software. Or find corner cases that need special handling or preparation.
When drafting training materials and providing training, you should focus on the task that needs to be completed, not on how it should be done. Often a different approach will yield additional benefits.
Talk to others that already made the change
Try to find other people who are (or have been) in the same situation. Ask about their experiences and learn from others who are already using a certain application. Register for project mailing lists, consult the internet, speak to friends and acquaintances. Start a discussion group on Yahoo or Google, or take part in an existing group discussion. Collect as much technical and cultural information as possible from all these parties. The experiences of others can be invaluable.
The migration may involve new software and adapting software already in use. Bottom line is that ODF is the new default file format for everyone's work - the use of older file formats is an exception for well defined cases, where other parties or old software is involved that does not yet support the use of ODF.
Using new software
- Introduce it soon.
- Existing software may be available for a limited time.
Introduce any new software that you need to fully support ODF as soon as possible on every desktop.
For mobile devises there is a variety of solutions available, including apps for viewing, editing and web based solutions.
We recommend that the current software will be available for a short, pre-determined period of time. Preferably not on everyone’s PC, but on a fall-back system. This offers an escape for the processing of older documents in case there is no direct solution/help available. The use of this has not to be too easy, because it may be an invitation for some people to delay the switch to the new solution, while in the beginning the users have fresh training and most support available.
People that for specific tasks will not make use of the new standard office-software, must use the old software only for those specific tasks. All other word must be done in the default software with ODF.
Obviously in the phases where decisions for the migration were made, taken into account are price advantages of free software and possible license constraints for the continuation of the use of the old software.
Adapting software already in use
- Inform software suppliers well in advance.
It may be that the office-software present already fully supports ODF. In that case the default format should be switched and templates and other default documents prepared.
All software suppliers that need to take action to support ODF natively, should be informed well in advance to give them enough time for the work.
Templates and documents
Templates and default documents
- Proper preparation and conversion important.
Users facing a new situation will typically look at the output and compare the look and feel with what they are used to. So for a positive experience it is very important that templates and other standard documents are well prepared to function perfectly with ODF.
Organisations may hire a professional consultant to do this, which means that once the budget is allocated, the work itself will not require much attention.
What to do with existing documents
- General policy: don't touch.
In general the existing documents should be left untouched. They can always be opened in a viewer or the current software for reference or to take parts from. Older documents should not be a regular part of the work flow. So if they are, it is advised to look at the organisation of the work.
Designing the work flow
- More efficient work with specific tools and use of PDF.
- Plan work with external parties.
Work flows could benefit from introducing bespoke tools that are streamlined towards the main tasks. The use of desktop office tools doesn't have to be the most efficient for the users. Offering simple, tailor-made solutions may significantly raise productivity and lower error rates. Also, tools that are web-based can be used on any device.
In many cases it is not needed to use editable office documents. Increasing the use of PDF should be considered.
In case where exchange of editable documents is mandatory, work on the content first and do the final full formatting as a last step.
- Automatic conversion and communication
Try to make it convenient to handle incoming old formats through email by for instance automatic conversion, and sending an automated reply back to the sender that his or her document needed to be converted. It is socially awkward for humans to signal this manually every time, but such a notice back sends an important message.
Social aspects and communication
- Goals must be clearly.
- Positive communication and signals.
- User expectations must managed.
In every phase the goals of the project should be explained clearly. Why has been chosen to switch to ODF? Users should be given the true and positive reasons to migrate and to co-operate.
The way in which users talk about a product - and in particular the most prominent users in an organisation - has a very real effect on the acceptance of that product. What the head of marketing or the CEO says about it, what Jenny (who has worked in the organisation for 30 years) thinks about it, what the author of the internal company magazine writes about it, these are all very important aspects.
Every time something that involves a large group of people has to be done - whether this is the implementation of new software, new soap dispensers or a new bikeshed - unexpected problems will occur. One cannot "plan too much" for a project in which a lot of people are involved.
While it makes sense to allow time for new technologies to settle in with the organisation and its processes, you need to be clear what will be supported and what not at the end of the migration process. Set out an explicit policy and publish a clear, strict deadline.
Ask users for advise on their work and important tasks, to help preparing tools, tests and trainings.
Find the ambassadors
- Find the potential ambassadors and involve and help those in a special way
Identify, involve and train potential internal experts, that have a talent and curiosity for innovation; people that are respected by their colleagues. They will be an example in the new situation and can also assist others by answering questions.
These ambassadors can be taken to special invents with explanation about the plans and the benefits. They can be asked for their advice, for example how they perform their work on a daily basis and ensure that they do not encounter any problems. Use their advise to decide about the spending of funds, and do tell them are spent. If new software will be deployed, give demonstrations and show some of the cool functions of the software.
In lager groups there will always be at least one who does not want to change to a new situation. Be prepared for that, and address the resistance in a friendly, helpful but decisive manner.
Reward, use gadgets
- Positive communication by gadgets and handy tools
- Meetings and demonstrations
Get the message out clearly and positively by using recognisable communication with maybe a mascot or T-shirts or coffee mugs printed with a nice logo, a joke or a pun.
Organise work meetings or lunch meetings, or give short demonstrations to show how documents will be processed in the future. Ensure that everyone attends at least one information session.
Prepare or find quick reference cards on the internet. Spread these amongst the users or develop amended cards yourself to place on every desk. Work with rewards: for example, give a sticker, magnet or button to everyone who asks a question during training. You can even turn it into a competition and reward the users with the most or best contributions with a special prize, for example an tablet.
- There are many possibilities to show appreciation.
Demonstrate publicly your appreciation for the efforts users make. This can be included in letters, demo's and training events: the users are the ones who will do the actual work. It is an important task and that must be recognised with a lot of sympathy. It is also possible to specifically reward people.
For example, the first department that switches over completely, the person who puts the most cool tips about the new software on the companies intranet, or the person who converts the most files. Prizes can vary from a pizza during lunch to a day off work or a weekend getaway. As long as it suits the users and the budget.
Think of a joke or make a bet. Perhaps you can get your manager to walk around in a silly T-shirt for a whole day, or to turn up for work with his hair dyed green on the day of the successful migration. <figure><title>Fokke and Sukke organise OpenDoc Society launch</title> <mediaobject><imageobject><imagedata fileref="images/OpenDocSociety.png" format="PNG"></imagedata></imageobject> <imageobject><imagedata fileref="images/OpenDocSociety.eps" format="EPS"></imagedata></imageobject> <textobject><phrase>Fokke: Bit quiet today… Sukke: Please tell me you didn't send the invite _only_ in ODF?</phrase> </textobject> </mediaobject> </figure>
- Use phases, deadlines.
- Make use of prior experiences.
Work in clearly defined phases, if needed per team or functional department in the company or organisation.
Set out an explicit policy and publish a clear, strict deadline. Communicate the most important dates of the phases and steps. Tell users how they can help to achieve the goals.
Similar organisations all over the world have done a migration before. Draw from the experiences of those who have already started the migration process or have completed it.
Make a plan for the transition phase
- Inform everyone in detail.
- Make sure that all ways of support are known.
Inform everyone about the transition plan in a timely manner. Tell all the users or groups of users when their turn will come and when they will receive the required time, training, manuals and rewards.
Ensure that everyone is fully aware of the fact that they are not simply being thrown in at the deep end. Let them know that they can count on assistance for possible problems, install a hotline if necessary. Ensure that people know that the transition will take place and that resistance is futile. Be clear about the deadlines and be strict too.
- Planning and changing habits are key.
Let everything happen according to plan and make the switch. In case where new software is introduced, effectively remove the old software from all computers - except for where you have determined that it could remain to deal with difficult cases. People use what they are familiar with. So ensure that they must change their habits.
- Many users have limited skills and must be trained properly and in advance.
- Make users being involved
It is important to take into account that many users have limited, self-taught skills. Often 'just enough' to help them surviving with their daily tasks. Even updates of the same product, another default scaling factor of the document or a friendly usage tip that pops up on the user screen is known to confuse and stress some users, let alone introducing another work flow or user interface.
The users have to be trained before the change, and thus, if new software is involved, before that software appears on their computer. This helps to prevent them getting lost and creating a negative mindset.
If there is a work flow, make sure it is written out so people can put a printout next to their computer and learn step by step.
Ask users for advise on their work and important tasks, to help preparing tools, tests and trainings.
Trainings for new applications
If new applications are deployed, and old applications are phased out, users should be prepared:
- if plug-ins for existing applications are no longer in use, and will need to know what to do;
- to know where to find help, training materials;
- by learning different application look and behaviour, for example:
- the menu structure
- drag and drop
- side panels and floating menus
- clipboard functionality
- keyboard shortcuts
- special characters
- file management
- saving files and version control
- find en replace
- grammar checking
A must have in trainings: better documents make a better migration
Many of the potential problems with migrating to ODF as new document format can be easily avoided if the authors apply formatting in a proper way. The next five simple guidelines will everyone's life much easier:
- Avoid direct formatting. Use character and paragraph styles. If for instance a different font size, font type, colour, letter spacing and indentation are needed to distinguish the headings or quotes in text, this must be done by using (and if needed creating) appropriate styles for the different elements in the document. Apply those styles to the relevant parts. Marking something up as a header directly impacts the structure of a document. Merely making a few letters look different through direct formatting conveys no meaning about the structure and is very difficult to maintain or reuse in a consistent way.
- Use paragraph style settings to determine the space above or below a line or a paragraph, instead of hard returns (with the enter key), particularly in lists.
- Use the text flow properties of a paragraph instead of manual page transitions.
- Do not use tabs or spaces to align text. Use specific tab-stops, or even better, a table.
- Avoid proprietary fonts that are bound to a platform or a (version of a) product, for which embedding in a document is not allowed. If possible, use only fonts that are generally available or that can freely be distributed and embed these in your documents.
New software may New software may have even more cool functions
- Demonstrate that alternatives have even more cool functions
One thing that users like are extras. This has nothing to do with the software itself. One example is the large clip-art collection in Word: nice, but not essential. However, if lovers of "goodies" like this are shown the amazing collection of open clip-art, they will flip out completely.
There will be other nice extras to show. Use those opportunities to win the people's hearts and minds.
Training for Training for conversion to ODF
Organise a few "conversion sessions" to show users that there are no problems. Take a number of test documents that they have created and get them to convert them to ODF. Create awareness at an early stage that conversions will not always be perfect. You will see some differences. Tell users who they can contact if there are any problems. If users ask you for help with a conversion problem, always check first whether it is really necessary to convert all or part of this document. Sometimes it may be possible to create a PDF of the relevant file and leave it for what it is.
Outline of the trainings and extra support
Trainings may consist of various parts.
- A limited training session for all users.
- In large deployments, a train-the-trainer program can be used, to limit cost for external support.
- If new office-software is deployed, the people that make heavy use of certain documents must get specific trainings.
- Provide clear and task-specific tutorials.
- After the trainings there must be short sessions for extra questions, and staff available at certain time to help.
- If new office-software is deployed, hand out CDs or USB-keys with software and documentation, so that the users can use it at home to.
The ODF Business Case Toolkit
What is the ODF Business Case Toolkit?
Gaining insight into the costs can help you to determine which migration path you will follow. Once you know what your budget is and what the actual costs of migration are, you can adjust the migration process accordingly. The ODF Business Case Toolkit is a set of questions that will help you in the further analysis of your IT environment and in making a schedule. The Toolkit examines the financial and qualitative aspects of your current environment. There are three possible answers to each question:
- Yes: this is the case in my IT environment.
- No: this is not the case in my IT environment.
- Further analysis required: this question cannot be answered unambiguously. The costs will be incurred primarily in the areas for which you give this answer.
Other tools for migration
All large suppliers offer services related to scheduling the migration, predicting costs, converting documents, adapting and integrating the applications and tools that they offer, training and technical support, with or without co-operation from local partners.
As with all projects, the golden rule for the implementation of ODF in a business environment is "look before you leap": analysis and planning are half the solution to a problem. The other half of the solution is the maxim "good agreements make good friends": communication with the users is of utmost importance, because they are the only ones who will in the end have to produce the goods.