Office 2010 Migration for Law Firms

18
Jun
2010

Fred Yeomans

Microsoft Office 2010 was only released a little over a month ago, but for me it seems to have been around for quite a while because of work I have been doing with the pre-release and beta versions. Over the past number of months we have been working with law firms regarding strategies for taking advantage of the new features of both Office 2010 and SharePoint 2010.

While Office 2010 introduces many important enhancements and new features (here is one view of the top new features for law firms), a firm obviously cannot take advantage of these features if they are tied to an older version of Office through a collection of legacy templates, customizations, and third-party add-ins and integrations.

So a significant part of our analysis has centred on how to migrate these existing capabilities to Office 2010, allowing firms to then take advantage of the new features. I would like to share some of our experiences here, primarily with respect to Word (though much of the experience applies to other Office applications as well).

Overall Strategy
Very few (if any) firms use MS Word in an “as-is, out-of-the-box” state. Most firms obviously have a significant investment in their MS Office deployment. This investment generally spans three categories:

1. Custom Templates: Most firms have a large number of custom templates, often many hundreds. These templates range from simple layouts, to complex templates with boilerplate text, user interface and code to support conditional text or formatting, to integrations with backend systems.
2. Application Customizations: Most firms also have application-level (i.e. not specific to a template) customizations in the form of macro libraries (or code add-ins) which automate common tasks, along with user interface customizations to menus and toolbars to access these macros.
3. Third-Party Add-Ins: Finally, there are usually third-party add-ins which provide either functionality not available in the applications, or enable integration with other systems (DMS, for example).

Each of these categories has its own migration challenges and strategies, which will be discussed below.

Before getting into specifics, however, there is a significant strategic question to be answered: how do you want to approach your migration?

One option is to do the minimum amount of work possible to make existing customizations and functionality work in Office 2010. Leave your macros alone except where you absolutely have to change them. Leave your UI customizations the same to the extent possible. This approach will probably be cheaper and take less time, but offers nothing in terms of strategic value or improved productivity.

The second approach is to redesign your customizations to fully take advantage of the Office 2010 development model, and the Office 2010 user interface model. While this approach may be more expensive up front, it opens the door to taking advantage of Office 2010 productivity enhancements and leads to a stronger strategic position going forward (not to mention giving you a chance to do a little housecleaning during the migration). While this is obviously a decision which needs to be made within the context of your firm, this is the approach we have been recommending, whenever possible.

Template Customizations
It is important to do some upfront work in performing an inventory of your existing templates, and how they are used. This permits an analysis to be done regarding how to migrate different types of templates.

We have found that custom templates usually fall into three categories:

1. Forms implemented in Word (requisition forms, expense forms, etc.)
2. Simple templates: Custom formatting, but no logic or conditional content
3. Complex templates: Custom formatting, with (sometimes extensive) logic for controlling content and layout based on user selections through associated custom user interface elements

The recommended approach to dealing with forms implemented in Word is to migrate them to a true electronic forms tool, such as InfoPath.

Simple templates can usually be migrated directly, with minimal change, though it is important to look at your templates and determine if you still need them all, or if there are better approaches. Often there are many similar templates which differ only in things like letterhead, headers or footers, etc. In Office 2010, the same flexibility can often be achieved in other ways (through custom quick part galleries, building blocks, and content controls, for example), allowing you to greatly reduce the number of templates which need to be managed.

Similarly, it is important to assess your complex templates and determine how best to migrate them – directly one-for-one, or by consolidating some and taking advantage of new Office 2010 features.

A decision also must be made as to how to implement often complex document creation user interface behaviour. It previous versions of Office, this was frequently implemented using a custom dialog which collects appropriate information regarding the type of document, jurisdiction, user, client, etc. In Office 2010, the Backstage user interface (shown by clicking the File tab) allows significant customization of the new document interface, while staying within the Office UI paradigm more cleanly.

Closely related to templates are custom styles. While most styles will migrate cleanly to Word 2010, it may be useful to make use of new features such as Style Sets.

Application Customizations
The vast majority of application-level customizations we have seen consist of VBA macros and associated toolbars and buttons. There are frequently hundreds of these macros. While most VBA functionality can be migrated directly, it is important to check for Compatibility. Microsoft makes available the Microsoft Office 2010 Compatibility Inspector, which compares existing (legacy) code against the Office 2010 object model by using a text search for known properties and methods that have changed.

Even for macro functionality which is still compatible with Office 2010, you may want to consider migrating to a managed-code, .NET development model. This approach enables a stronger development model, as well as a stronger, more flexible deployment and supportability approach than VBA.

On the user interface side, there have obviously been significant changes in Office 2010. How significant the changes are depends on whether you are migrating from Office 2007 or an older version. Rather than just creating a one-for-one mapping of your existing toolbars to new ribbons, you should take the time to determine whether your customizations should more correctly fit within the existing structure. For example, should your custom printing behaviours really go in the Backstage with other print tools? Should your table-related tools go on the Table ribbon and this take advantage of the context-sensitivity inherent in the user interface?

Third-Party Add-ins
Third-party add-ins represent a significant challenge when migrating. Not all vendors update their add-ins as quickly as we might like. Sometimes updates to add-ins are attached to a requisite upgrade to backend systems. And most frustrating is that all of this is out of your control.

It is important to assess all of your current add-ins to determine if they are still necessary in Office 2010. Some functionality, such as scrubbing of hidden data and conversion to PDF may be available in an acceptable way within the new version of Office.

It is also important to prioritize the importance of various add-ins to support decision making when you are trying to decide if an upgrade is feasible for your firm.

Other concerns
There are a few other areas to consider when planning your migration to Office 2010. Many firms collaborate with “outsiders” on documents. What are the implications of this collaboration for your customization strategy? Some approaches may lead to documents which are not compatible with older versions. Or, if you save them in a manner compatible with older versions, you may lose certain functionality when the document is changed by others outside your firm.

Another important area of consideration is packaging, deployment and support of your custom assets. This has traditionally been challenging. While Office 2010 provides an improved infrastructure to support this, it is important to dedicate some effort up front to determine your strategy.