Because OpenOffice is free and you have to pay a substantial
fee for Microsoft Office, you might be tempted to migrate your entire
organization from Microsoft Office to OpenOffice. After all, migrating to
OpenOffice would save an absolute fortune in Microsoft Office licenses, which
is important in a time of shrinking IT budgets. Before you jump right in and
begin a migration, though, there are a few issues that you need to be aware of.

Before you begin

Before you commit to a migration, you need to be aware that
with OpenOffice, you get what you pay for. When you buy a copy of Microsoft
Office, you’re buying a mature suite of many different products. Your
Microsoft Office purchase also entitles you to technical support. Although
OpenOffice is comparable to Microsoft Office in many ways, there are a lot of
places in which it’s seriously lacking. For example, technical support is
pretty much limited to whatever information you can find on the Internet.

Another major limitation to OpenOffice is that, although it offers programs that compete with Microsoft Word,
Excel, and PowerPoint, it does not offer products similar to other Microsoft
Office applications. The most notable example is that there is no OpenOffice
version of Microsoft Outlook. You can also forget about getting OpenOffice
equivalents to Microsoft Office 2003 products such as Microsoft OneNote,
Publisher, InfoPath, and Access.

I’ll be the first to admit that there are decent open source
database and desktop publishing applications. The fact that OpenOffice doesn’t
offer such programs might not be a big deal since you can get these types of
applications for free from other places. However, even if equivalencies to
Word, Excel, and PowerPoint were all you needed, you should still think twice
before giving up Microsoft Office in favor of OpenOffice. That’s because the
programs that come with OpenOffice do not have as many features as their
Microsoft Office counterparts.

Unless you’re a power user, you may never even notice the
features that are missing from OpenOffice. The majority of the missing features
are things that the average user doesn’t tend to use. Even so, the missing
features can make converting Microsoft Office documents to OpenOffice format
difficult. For example, in Microsoft Office, macros are encoded in Visual Basic
Script. However, OpenOffice doesn’t support Visual Basic script.

This means that if you have a Microsoft Office document that
you want to convert to OpenOffice, and the document contains macros, you’ll
have to completely recreate the macros once the conversion process is complete.
You can open a Microsoft Office document containing macros into OpenOffice, but
the macro code will not do anything. You can view or edit the code, but you
can’t execute it.

Even though macros are the biggest cause of
incompatibilities between Microsoft Office and OpenOffice, there are other
types of things that are sometimes included in Microsoft Office documents that
tend to cause problems with the conversion process. Other document features
that are not supported by OpenOffice vary among document types. For example, a
Microsoft Word document may not be converted to an OpenOffice document
correctly if it includes AutoShapes, revision marks, OLE objects, indexes,
tables, frames, multicolumn formatting, hyperlinks, bookmarks, Microsoft
WordArt-based graphics, animated characters, animated text, or certain controls
and Microsoft Office form fields.

Likewise, there are also some features that might be found
within a Microsoft Excel document that may not convert correctly. These
features include AutoShapes, OLE objects, pivot tables, new chart types,
conditional formatting, some functions and formulas, and certain controls and
Microsoft form fields. There are also restrictions on PowerPoint documents,
although there are not as many restrictions for PowerPoint documents as there
are for Word and Excel documents. OpenOffice has trouble converting PowerPoint
documents that include AutoShapes; tab, line, or paragraph spacing; master
background graphics; grouped objects; and certain multimedia effects.

Migrating to OpenOffice

If you have read the previous section regarding OpenOffice’s
various limitations and you still want to migrate from Microsoft Office to
OpenOffice, then there are a few challenges that you’ll face. One challenge
is the actual deployment process. When you install OpenOffice, the installation
program does not offer to uninstall Microsoft Office, and the installer does not
attempt to configure OpenOffice based on your Microsoft Office settings.

OpenOffice is configured pretty well by default, but if
there are one or more settings that need to be changed, it would be a real pain
to have to modify these settings individually on every PC to which you are deploying
OpenOffice. If you find yourself in a situation in which some of the
configuration options need to be changed for all of your users, then I
recommend creating a custom Windows Installer package.

A Windows Installer package is an MSI file that you can use
to deploy the application. You can create a custom MSI package by using a free
utility called WinINSTALL
LE 2003
.

What makes this utility so perfect for this type of
deployment is that it uses a procedure called diffing to build a custom installation script. Basically, the way
the diffing function works is that you would load Windows onto a PC and
then install the same service packs and hot fixes as are being used on your
workstations. You would then take a snapshot of the machine’s hard drive by
using the WinINSTALL LE 2003 utility.

After taking the snapshot, you would install OpenOffice on
the machine and then configure OpenOffice in exactly the way you’d
like it to be configured for your users. This means doing things such as
setting up data paths, possibly placing an icon on the desktop, or even
configuring Proxy Server options.

Once OpenOffice is running an ideal configuration for your
environment, you’d run WinINSTALL LE 2003 again and make a second snapshot. The utility would then compare the two snapshots. The
MSI file that is created is basically a log of all the files and registry
entries that vary between the two snapshots. At the time the MSI file is
created, a folder is also created to hold all of the files
associated with OpenOffice.

One word of caution: WinINSTALL LE 2003
doesn’t just look for new files; it also looks for any files that have been
modified between the two snapshots. For this reason, it’s extremely important
that the machine used to create the MSI file contain nothing but Windows and
OpenOffice. It’s also very important that you deploy the MSI file only to
machines running the same operating system and service pack level as the
machine used to create the Windows Installer file.

Ideally, you could use SMS Server to remove Microsoft Office
from all of the workstations, and then deploy OpenOffice by using the Windows
Installer package that you created. If you don’t have SMS Server or a
third-party application management utility, you can use Active Directory to
assign the application to the desired users.

Assigning an application means that Windows will
automatically install the application the next time a user logs in. If a
user somehow manages to destroy, damage, or disable OpenOffice, Active
Directory will use the MSI file to figure out what has been changed to cause
the malfunction and will repair OpenOffice. As you can see, by creating an MSI
package for OpenOffice, you can automatically deploy a custom OpenOffice
configuration and automate the repair process should a user damage
OpenOffice.