In virtually every RFP we receive, we always get the same extensive list of questions on features, security, and data protection.

Here’s one question we never get:

"What is your plugin architecture based on?"

From personal experience, we cannot stress the importance of this question enough. 

Old MS Word plugins are built on the COM and VSTO architecture. These plugins work by spreading their tentacles deep into the bowels of MS Word to allow them to manipulate it in the same way a puppeteer manipulates his puppet’s strings.

The plugin's freedom to do whatever it wants, has significant drawbacks:

  • Instability: any programming mistake can cause Word to crash, or cause mysterious errors.
  • Plugins cannot play together nicely, and can easily step on each other's toes. Again, causing crashes.
  • Complex Updates: Patching these add-ins isn't straightforward. IT admins often struggle with compatibility issues.
  • Slow: the old plugins rely on local memory and CPU resources. This slows their launch time significantly.  

Eventually, Microsoft took notice and created a new type of plugin architecture called (a little bit uninspiringly) “Office Add-Ins”. 

Plugins of the new generation:

  • Do not consume local memory or CPU resources, ensuring better performance.
  • Are pushed from the cloud, meaning no local installations.
  • Are based on modern web technology, and can therefore run on Windows, Mac, mobile devices and even in browsers.

But just because this new technology exists, does not mean that vendors are spending time and money converting their existing applications towards the new plugin architecture. In fact, for many existing plugins that have been on the market for quite some years, this conversion is simply impossible to do, because a lot of functionality they rely on is deliberately forbidden in the new plugin architecture.

The inherent issues are often not detected until a proof of concept or until the contract has already been signed.

When shopping around for a new plugin, ask your vendor whether it uses the old "COM" or "VSTO" architecture, or instead the new "Office.JS" architecture.

‍

EDIT 30/07/2024: since this post was released in September of 2023, Microsoft has taken further steps to eliminate the old plugin architecture, starting with Outlook, which also leverages the old COM and VSTO architecture. 

In a recent update, Microsoft shared that they will “be improving the Outlook experience across platforms by unifying it into a single web codebase.”

Translation: Microsoft is disabling COM and VSTO plugins for the new version of Outlook, which comes standard for Windows 11 devices. If you have an older device, as most legal teams do, you can continue to use the classic Outlook without support. Or you could switch to a different provider, but let’s face it – Outlook is the legal sector’s go-to email provider. That won’t change anytime soon.

If you work with Outlook plugins, it’s best to (1) check whether the plugins in question are built on the old architecture, (2) check whether they use functionalities that are no longer allowed under the new architecture and (3) talk to your vendor to see what their migration plans are, if indeed they are capable of migrating at all.

For MS Word plugins, the pressure to act isn't as high as with Outlook yet. Microsoft has made no explicit claims of phasing out the old architecture in Word the way it has with Outlook. But this will undoubtedly be on their roadmap. Our recommended course of action is in any case similar to the above. Start visualizing which tools you may be about to lose, talk to your vendor to see how they are dealing with the situation, and, depending on the criticality of the tool in question, start considering your transition plan.

Click here for more information on how ClauseBase is tackling these issues.