LibreOffice emerged from the former OpenOffice.org project and is now supported and promoted by hundreds of community members worldwide. The number of active developers (code contributors) is particularly high. LibreOffice [1] is backed by The Document Foundation [2], a non-profit organization based in Berlin that operates the necessary infrastructure (server, websites, build systems) and holds the name and code rights, which guarantees independence from individual company interests and provides a certain degree of future-proofing for the user.

LibreOffice is a complete office suite that comprises word processing (Writer), spreadsheet (Calc), presentation (Impress), vector art (Draw), and database (Base) modules, as well as some auxiliary modules. Thus, it fully covers the usual application requirements for an office work suite in the enterprise. The open API allows both the program modules and the basic application to be adapted and controlled with macros for automation and to meet the needs of custom applications.

With the use of configuration files, LibreOffice can be customized to the needs of the company and secured with appropriate certificates – both the documents and the connections. The cloud version (LibreOffice Online), which has been under development since 2016, has a communication strategy in which online and offline versions can be set up on your servers, independent of the operating system.

Adapting the Community Version

LibreOffice is an open source project and not a program to be used out of the box in the enterprise, which has some consequences for operations. The community regularly delivers pre-compiled program versions, which can then be installed easily and work immediately. Although this works perfectly well for the private and the self-employed user, these packages are not usually suitable for a company. The community packs every developed capability possible into the delivered packages; however, such a program is seldom seen in the enterprise. For example, consider the possibility of checking for an update and downloading it directly – not a good option for 1,000 individual users.

If you want to use LibreOffice in your company on a comprehensive and productive basis, you have to look intensively at the program and its community – and ideally even at the network – not only to understand the structures and leverage the support of the community, but also to decide what you really want from the program and how it can be achieved. Your solution could be a customized build or just special configuration files and extensions. The adaptation and tests are then carried out in-house before being implemented in the company. As a consequence, the IT department has to build up and develop competencies accordingly; only then can an open source project be used profitably in the company.

LibreOffice is rarely the first office suite a company implements, so the tasks usually involve migrating from an established office suite to LibreOffice. Every migration always has two components: the technical and the social (communication, users). Although the technical side is usually solved by the appropriate IT department, most migrations ultimately fail on the user side. If you are thinking about using an alternative office suite, you must keep a close eye on the users and motivate them with appropriate means and in a timely manner.

The Technical Side

For years, office programs have been rather neglected by IT. A program is rolled out, maybe even with some first-level support, and that is it. In contrast to databases, servers, and mail programs, the software is left to the user to figure out. At some point, this plan will backfire, and issues must be solved during migration, at the latest. Office programs can do much more than just write letters, calculate spreadsheets, and create presentations.

Users have optimized their work processes around the possibilities of the programs they use and have automated them with the help of macros. With the built-in database modules, applications can be created without any real programming or IT knowledge, thus creating a world of applications outside of the classical IT organization. In very few companies will you find clear rules on documentation requirements, programming guidelines (for macros and user customization), test cases, document formats, and more. The result is that, if a small glitch arises in the existing underpinnings, processes suddenly cease to function, and the effects can be dramatic.

LibreOffice is not a clone of another office program and cannot be used as an exact replacement, even if the functions are similar or even identical. These general conditions, then, determine the points to be examined beforehand and the resulting measures to be taken (Figure 1):

• Processes. How is the established office suite used? Which (operationally relevant) processes does it address?
• Macros. Which script-driven applications are used in the company? Who created them? Which processes were improved or even made possible?
• Custom applications. What other (custom) programs use the office suite as an essential part of their processes? How is the office program called and how does the further processing proceed? For example, many custom programs use a specific office product as the output target.
• Documents. Which documents and templates are available? How complex are the documents to be created? What paths do the documents take, and which mandatory specifications exist with regard to a certain document format (storage format), especially when exchanged with external groups?
• Databases and database applications. Which databases (file databases) are used in-house? Who created and maintained them? How are they integrated into processes?

Figure 1: Steps for migrating to LibreOffice.

Although many of the questions need to be solved and documented for established software, anyway, they certainly have to be addressed in the case of migration. A suitable test scenario and corresponding test cases would be helpful, making it easier to assess the expected expenditure.

Each of these points is relevant to the process, and disruption would hinder the accustomed workflow and affect productivity. Also, unresolved dependencies have a negative psychological influence on the affected users and thus have a counterproductive effect on the planned change.

Stumbling Block: Document Formats

Document formats are one of the biggest challenges. If Microsoft Office has been used exclusively for many years, no one has had to worry about file formats. Virtually every business partner uses these file formats, and in the past, Microsoft has taken care of compatibility between different variants when changing versions, although this strategy has recently been abandoned and will be noticeable in the next few years. Nevertheless, the often huge stock of old documents and the need to exchange documents with external agencies remain.

Years of ingrained behaviors are not easy to overcome, which is one of the great challenges of migration. To go down the route of least resistance and save all data in third-party formats is unfortunately not a solution. Although LibreOffice supports exporting to many current formats, each conversion entails a risk of loss. The full range of LibreOffice functions can only ever be saved correctly in the native file format, and that is the Open Document format. If you change this, you run the risk of not finding your document as you left it the last time it was saved. Strategies must therefore also be developed for dealing with third-party documents.

Switching to LibreOffice (or any other office suite) is not just a simple program exchange; rather, it has a profound effect on processes and workflows. Consequently, a corresponding project also needs to be equipped with technical and personnel resources. The procedure can be roughly divided into the following steps:

• Analysis phase. An inventory of the current situation is prepared, focusing on the above-mentioned points.
• Evaluation phase. The points found are now evaluated and solution strategies are developed: As a rule, all documents that have not been changed for a year can be easily archived (PDF or images), macros can be checked to see if they are (still) necessary or can be handled in other ways (process changes), databases can be transferred to physical internal databases, and front ends can be redesigned (e.g., as web applications).
• Test and conversion phase. All necessary processes are tested on the new office suite, typically in a test environment, including the creation of new templates and macros that are important for the company, programming any necessary interfaces to specialist applications, and so on. At the same time, the LibreOffice program is being adapted for use within the company. During the rebuilding phase, operating instructions are also drawn up with regard to the document format, definitions of exceptions, and definitions of any special workplaces (with the old office suite). This phase runs parallel to the training of employees and involves at least some power users.
• Rollout phase. The conversion has now happened, including the conversion of all processes. With very good preparation, this phase is short and trouble-free.
• Support phase. Prompt and qualified support is absolutely necessary, especially in the beginning. Templates and applications can also be improved, but it is usually training and customer problem-solving that you need in this phase.
• Maintenance phase and operation. Work continues as before the migration. The cases created and used in the test phase are further developed and documented, and they are used as a basis for updating to a new version.

Experience has shown that such a project takes at least six months, which puts the question of the version to be used into perspective: With a normal LibreOffice version cycle of half a year, you should always use the very latest version at the beginning of the project, even if it is still unstable. By the time the test phase is completed, the program version will be stable and can be rolled out without any problems. On the other hand, if you were to use the current stable version at the start of the project, it would be obsolete (unavailable and in or through the end-of-life period) by the time of the rollout – a big disadvantage when you try to communicate the benefits.

The technical advantages of switching to LibreOffice are easily identifiable and beneficial for a company, without even mentioning the savings in terms of licensing costs and licensing management, which is not required for LibreOffice. With an open source product, more responsibility is transferred back to the enterprise, which also means more scope for creativity. The company's own competencies are naturally built up internally, which can lead to an improvement in processes and overall productivity. The wide range of options for configuring and maintaining an open source product such as LibreOffice to suit your company and your own requirements boosts flexibility and independence. Additionally, you have the freedom to choose the correct operating system without affecting the office package – an unbeatable advantage.

However, experience also shows that the way of thinking in IT departments must change, leading to more personal responsibility and initiative. Many solutions are only available in communities, forums, or chats and need to be actively sought, so you become part of the network.