Office suites: a clear guide with practical examples

Nobody buys an office suite for the word processor. Every serious suite can write a letter, add up a column, and put words on a slide. If that were the decision, it would have been settled a decade ago.

What you are really choosing is a bundle, a file format, and a set of habits, and of those three, the file format is the one that decides how expensive it will be to change your mind.

What you are actually buying

An office suite in this market is rarely three applications. It is a package: documents, spreadsheets, and presentations, plus some combination of mail, calendar, file storage, meetings, and an administrative console to run it all.

That matters for the comparison in two ways.

First, the price you pay is for the whole bundle, so the honest question is not "is this word processor better" but "is the weakest component in this bundle one I can live with, or will I end up buying a separate product for it anyway?" A suite that saves money and forces you to buy a standalone meeting tool has not saved money.

Second, the bundle is where lock-in accumulates. Documents alone are portable enough. Documents plus mail plus storage plus identity plus meetings, all wired together, is an ecosystem, and unpicking it is a project rather than an export.

The five things that actually differ

Strip out the feature lists and the differences that survive are these.

1. Document fidelity across systems. How well a complex document made in one suite survives being opened, edited, and saved in another. This is the single most consequential difference and the least discussed.

2. Whether the desktop applications are first-class. Some suites treat the browser as the real product and the installed application as a companion; some do the reverse. Neither is wrong, but the mismatch between the two is felt daily by anyone who works offline, works with very large files, or has years of keyboard habits.

3. The collaboration model. Simultaneous editing by several people, versus one person at a time with the file checked out. Both are legitimate designs and they suit different work.

4. What the administrative layer can do. Sharing defaults, retention, recovery of deleted work, audit logging, and how a departing employee's documents are handled. Invisible in a demo, decisive after two years.

5. Extensibility, and what you have already built on it. Templates, macros, add-ins, and documents that reference other documents. This is the accumulated estate, and it is usually the reason a switch is impossible rather than merely inconvenient.

Format fidelity is the real lock-in

Every suite can open the others' files. That sentence is true and misleading.

Opening a document is not the same as round-tripping it, opening, editing, saving, and having someone on the original system open it again unharmed. Round-tripping is where things go quietly wrong, and the losses are rarely visible on screen:

Tracked changes and comments may be flattened, reattributed, or dropped.
Complex layout (text flowing around objects, multi-column sections, precise pagination), shifts.
Automatically numbered headings, cross-references, and generated tables of contents can lose their links and become plain text that no longer updates.
Spreadsheet functions that exist in one product and not another degrade to errors or to a frozen last-calculated value.
Macros and scripting do not transfer between suites at all. They are written in different languages.
Fonts that are not installed on the reader's machine get substituted, which changes line breaks and therefore page counts.

Two practical consequences. If documents leave your organisation for editing (to clients, lawyers, agencies, funders), you are constrained by what they use, not by what you prefer. And if you have a long document estate with heavy formatting, migrating it is a document-by-document exercise, not a bulk conversion.

The test is easy and almost nobody runs it: take your ugliest real document, round-trip it, and look for these six things specifically.

Browser or desktop: the question behind the question

The argument is usually framed as preference. It is really about three concrete situations:

Working without a reliable connection. Trains, sites, aircraft, rural offices. Find out what the offline experience is (full editing with later sync, read-only, or nothing), and test it by actually disconnecting rather than by reading the marketing.
Very large or very complex files. Big spreadsheets with heavy calculation, long documents with many objects. Browser-based editors have real limits here, and the failure is usually slowness rather than a clear error.
Long-established keyboard habits. People who are fast in a desktop application are often dramatically slower in a browser equivalent, and that cost is real even though it is invisible on a feature comparison.

If none of those three applies to your team, the browser-versus-desktop argument is not worth having.

Templates, macros, and the estate you forgot you had

Most organisations carry an estate they have never inventoried: the quotation template, the spreadsheet the finance manager built years ago that pulls figures from four other spreadsheets, the report that formats itself with a macro, the mail merge that produces the annual letters.

That estate is the actual cost of changing suite. Before evaluating anything, find it:

Which documents are templates that other documents are made from.
Which spreadsheets contain macros or scripts.
Which files link to other files, and whether those links are by file path, because a path-based link breaks the moment storage moves.
Which add-ins or plug-ins are installed, and who depends on them.
Which documents are produced automatically by another system.

You do not need to migrate all of it. But you do need to know it exists before you promise anyone a date.

What to test during a trial

Trials get spent making a new document, which proves nothing. Spend the time on the things that only break under real conditions:

Round-trip your worst existing document, in both directions, and check the six failure points listed above.

Have two people edit the same file at the same time, then have a third join. Watch what happens to formatting while they do it, and check what happens if one of them is offline when they make their changes.

Open your largest spreadsheet and use it properly: sort it, filter it, recalculate it, chart from it.

Delete something and get it back. Find the recovery window, and find out whether recovery restores the file's sharing state as well as its contents.

Share a document with someone outside the organisation and have them edit it, using whatever they normally use. This is where fidelity and access controls meet, and it is the scenario people most often discover after committing.

Print something that matters. Pagination differences between suites are real, and if you produce anything that must be a specific number of pages, this is not a small detail.

Look at the admin console for twenty minutes. Find where sharing defaults live, where the audit log is, and what happens to a user's documents when their account is disabled.

What is marketing

Some of the loudest differentiators in this category do not change a buying decision:

Raw counts of functions, templates, or file types supported. You will use a small fraction, and the fraction you need is either present or absent regardless of the total.
Assistive and generative features, which move too quickly to be a durable basis for a multi-year commitment and which are appearing everywhere at similar speed.
Storage figures quoted per seat, unless you have actually measured what your team uses. Most organisations are far below the ceiling, and the ones above it are far above it.
Uptime commitments quoted without the terms. What matters is what the commitment obliges the vendor to do when it is missed, which is usually a credit rather than a remedy.
Integration counts. What matters is whether the four systems you actually run are supported, not whether the total is in the hundreds.

Before you commit: the export questions

Ask these while you still have bargaining power:

Can an administrator export all documents for all users, without contacting support?
Does the export preserve folder structure, sharing permissions, version history, and comments, or only current file contents?
What format do documents come out in, and does that format open faithfully in something else?
What happens to documents owned by accounts that have been deleted?
After cancellation, how long is data retained and how long do you have to retrieve it?

"Your data is always yours" is a slogan. The answers above are the actual policy.

The cost of changing your mind

Not the files. The files move. The costs are:

Reformatting the document estate, particularly anything long, generated, or heavily laid out.
Rewriting macros and scripts, which do not convert and have to be rebuilt by someone who understands what they were for.
Repairing links between files when storage paths change.
Retraining, which is largest for your most productive people, because they are the ones with the most habits.
The bundle unwinding: mail, storage, meetings, and identity often move at the same time, and each is its own project.

Which is why the useful moment to think about all this is now, before signing, rather than in three years when the answer is fixed.

More on this site: office suite features, security settings, and how the options compare.