How to choose an office suite by document type, not feature lists

The honest answer to "which suite is best" is that it depends on two things, neither of which any reviewer can know: what your documents are like, and who else has to open them.

An organization whose output is short internal notes has almost no constraints and should optimize for cost and convenience.

An organization producing long structured reports for regulators, or financial models built over years, has few viable options and should stop reading general advice immediately. Same category, different decision: the difference is in your files, not the products.

What to take away

Five kinds of document work

Sort your real output into these. Most organizations find that one class dominates and one is small but critical.

Short internal documents. Notes, agendas, one page summaries. Every suite handles these. If this is the bulk of your work, most of this page does not apply to you and you should choose on price and on what your people already know.

Long structured documents. Reports, manuals, policies, submissions. These depend on heading structure, automatic numbering, cross references, generated contents, footnotes, and consistent pagination. This is the class where suites genuinely diverge and where a bad fit costs hours every week.

Precision laid out documents that leave the building. Proposals, contracts, anything on letterhead, anything a client or a court reads. Here the requirement is that the document looks identical everywhere, which usually means fixing the final form rather than trusting a shared editor.

Calculation heavy work. Models, budgets, forecasts, anything with links between files, external data connections, or scripting. This class has the least tolerance for approximation, and it is where an incompatibility does not look like an error, it looks like a wrong number.

Presentation and visual work. Decks that get presented, embedded media, precise placement. The risk here is fidelity when the file is opened on someone else's machine, an hour before it is shown.

Now weight them. Which class is most of your volume? Which class would cause a serious problem if it broke? Those are often different, and both belong in the decision.

The candidates, and the formats that carry them

The suites a business is realistically choosing among are Microsoft 365 (Word, Excel, PowerPoint), Google Workspace (Docs, Sheets, Slides), LibreOffice, OnlyOffice, Collabora Online, WPS Office, Zoho Workplace and Apple iWork. Microsoft 365 and Google Workspace are the two cloud subscriptions usually compared against each other; LibreOffice, OnlyOffice and Collabora Online are the open-source and self-hosted routes; WPS Office, Zoho Workplace and Apple iWork fit particular preferences. Each performs differently across the five classes above, which is why the classes come first.

Format matters just as much, because it is what crosses the boundary. Expect the Office Open XML family (.docx, .xlsx, .pptx, standardized as ISO/IEC 29500), the OpenDocument family (.odt, .ods, .odp, ISO/IEC 26300), and PDF, which fixes a final form that is not meant to be edited back. Ask which of those your external editors send and expect; that answer constrains the field before any feature comparison begins.

The constraint you do not control

If people outside your organization edit your documents, their software becomes part of your requirement. That is the everyday case for openly specified formats.

The UK government's guidance on working with open standards makes the same argument: a format anyone can implement remains readable after the relationship ends.

Ask concretely: who sends you files to work on, who you send files to for editing, and what each uses?

Clients, funders, lawyers, and accountants rarely change their arrangements to suit a supplier. Agencies and public bodies rarely do either.

If most of your outbound editable documents go to one kind of environment, that outweighs almost everything else on this page.

The related question is what happens at the boundary. A file that survives one trip and back is fine; a file that goes back and forth six times through two different products accumulates damage. If that is your working pattern, test it that way rather than once, and check the specific things our 2027 office suites overview lists as the common casualties.

Where an offer describes itself in loose terms, the standard definitions of cloud service models — software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS), set out in NIST SP 800-145 — are a fair reference for working out whether two candidates are even the same kind of purchase.

Disqualify before you compare

Four questions usually cut the field to two candidates in an afternoon.

Anything failing one of those is out regardless of how it looks elsewhere.

Score by class, not by total

An overall score is an average across unlike work, and averages hide exactly the failure that matters. Score each class separately, and treat each as a separate decision.

Fill this in with a verdict per cell, from your own testing, and the answer usually declares itself. Where a candidate is weak on a class you barely produce, that is not a reason to reject it. Where it is weak on your dominant class, no strength elsewhere compensates.

A worked example

Take a training company whose dominant class is long structured documents: course manuals with numbered headings, cross references and an automatically generated contents page, which its clients edit in .docx. Short internal notes and a few linked financial models make up the rest.

The dominant class is the first test. Word, Google Docs, LibreOffice Writer and OnlyOffice can all open a .docx, so the question is not whether they can, but whether heading structure, automatic numbering, cross references and the generated contents page survive a round trip through each of them, and then survive six. That is the test to run on your own worst manual, and the result narrows the field more than any feature list.

The models are the second test, where the standard is formula and link fidelity rather than layout. If they run on macros, the decision becomes a suite where those macros already work or the cost of rebuilding them, because macros do not convert between suites.

Running two suites on purpose

Most organizations of any size are already using two, whether or not anyone decided to. One arrived with the mail bundle, another came in with a department, and a third is what a contractor uses.

That is workable, and it goes wrong when it is unmanaged. If you are going to run two, decide three things explicitly:

An undecided boundary gives the worst of both: two subscriptions, two sets of habits, documents in both places, and no one sure which copy is current. A decided boundary is just two tools, a normal way to work.

Either way, count both subscriptions honestly in your cost model rather than treating one as free because it came with something else.

Common questions

Is the free option viable?

For short internal work, frequently. It becomes unviable at the point where you need administrative control over sharing, recovery of a deleted document, or any assurance about what happens to your files. That threshold arrives with your first employee who leaves badly, and it is worth crossing before then rather than after.

How much weight should familiarity carry?

Real weight for your most productive people, who are fast because of habits that do not transfer, and much less for everyone else, who adapt within a fortnight. Retraining cost is concentrated rather than spread, which is a different problem from the one it is usually treated as.

Do generative and assistive features belong in the decision?

Only as a tiebreak. They are moving quickly enough that today's comparison will not survive the length of a normal commitment, and they are appearing everywhere at similar speed. Choosing a suite for a feature that will be ubiquitous in a year is choosing badly.

What if we are already committed and it is a bad fit?

Establish which class is failing before you consider moving. Often the answer is a second tool for one class rather than a migration, which is cheaper, faster, and reversible. The rollout decisions matter more than which product you are on, and fixing those is usually where the improvement actually comes from.