How to run an office suites comparison by testing the seams

Put two suites side by side and the columns will mostly agree. Both write documents, both do spreadsheets, both have slides, both support comments. The grid says they are the same product at different prices, and the grid is missing the thing that actually separates them.

The office suites comparison most buyers run starts from the same shortlist: Microsoft 365, Google Workspace, and Zoho Workplace, bought as services, and LibreOffice and OnlyOffice on the file side, where the document file remains the unit of work. Treat each name as an example of an arrangement rather than as the thing you are choosing between, because the arrangement is what you will actually be living with.

What separates them is what a document is in each arrangement, and where the authoritative copy lives. That one difference propagates into backup, sharing, offline work, interoperability, and how expensive it will be to leave. Compare on that first, and the feature rows become a tiebreak rather than the decision.

What to take away

Three arrangements, not three products

The document lives in the service. There is no file until you ask for one. Version history, comments, and simultaneous editing are properties of the service rather than of a document, which makes them excellent. Backups are the provider's model rather than yours, exit means an export and a conversion, and anything that reads files directly needs a translation step.

The file is the unit, kept in sync. A real file exists on disk and the service distributes it. Anything that reads files works normally, backup can be your own, and offline work is straightforward. In exchange, simultaneous editing is harder, conflicts are a genuine event with two copies to reconcile, and version history is usually thinner.

The file is the unit, on storage you run. Full control, full responsibility. Everything is your problem, including availability, backup verification, and the collaboration features you now do not have. Legitimate for organizations with a specific requirement and a person to own it, and expensive for anyone choosing it by instinct.

Most offers are one of these with borrowed features from another. The useful question during a comparison is which one it is underneath, because that is what it will behave like on the day something goes wrong.

Compare the seams

The applications are the part you look at. The seams are where the work actually gets stuck. Where an offer describes itself in loose terms, the standard cloud service models — infrastructure as a service, platform as a service, and software as a service — help you decide whether two candidates are even the same kind of purchase.

For each seam, ask what happens if you change that component later. A suite that makes every seam a one way commitment is not cheaper; it is a decision about the next five years disguised as a purchase.

For Microsoft 365 that seam is identity in Entra ID and storage in SharePoint or OneDrive; for Google Workspace it is the Google directory and Drive; for a self-hosted OnlyOffice it is whatever directory and storage you run yourself. Ask each vendor which of those components you can replace without replacing the suite, and which ones you cannot.

For the questions about separation, resilience, and who at the provider can reach your data, the Cloud Security Principles published by the UK's National Cyber Security Centre work well as a ready made agenda that any supplier should be able to answer without a specialist.

Ask administrative questions three ways

Administrative capability is where comparisons go wrong most often, because the vocabulary is unstable. Do not ask whether a product has a named feature. Describe the situation and ask what happens.

Ask the same four of every candidate and record the answers verbatim. The differences will be large, and none of them would have appeared in a feature grid. The full set of feature checks works the same way, on the application side: styles and numbering, tables and layout, spreadsheet formulas and pivot behavior, chart and font fidelity, macro and add-in compatibility, and whether comments and tracked changes survive the round trip.

The trip that reveals the difference

Comparisons in this category are settled by interoperability, and interoperability is best measured with one deliberate exercise.

Take a real document with headings, numbering, a table, a footnote, and a chart. It also has a tracked change and comment, so send it to someone outside your organization using a different arrangement — a Microsoft 365 document to a LibreOffice user, for example, or the reverse.

Have them edit it properly, adding a comment and a change of their own, then get it back. Open it, send it out again, and get it back a second time.

Record what was lost on each trip and whether losses accumulated. Do this for every candidate with the same document and the same outside contact. You then have the only genuinely comparable evidence in your whole evaluation.

The failure points to look for are set out in the suite overview: numbering that restarts, tables that reflow past the margin, footnotes that move, fonts that substitute, chart data that loses its link, and tracked changes that arrive as plain text. Doing it twice matters because damage in this category is cumulative rather than immediate.

Breaking a tie honestly

If two candidates survive all of that and remain close, they are close, and there is no hidden fact that will separate them. Break the tie in this order:

Then write down what you chose, what you gave up, and what would make you revisit. Two years on, that note converts a renewal into a short check instead of a repeat of the entire exercise.

Common questions

How many candidates belong in the comparison?

Two, three at most. Beyond that the exercise stops being a decision and becomes a survey. Use disqualifying requirements to cut the field before comparing anything.

Should we compare on price at the start?

No. Price entered early anchors every judgment that follows. Establish which candidates could actually do the work, then price only those, in your own units.

What about running a mixed estate deliberately?

It is common and it is workable, provided somebody decides which arrangement holds the authoritative copy and which class of work happens where. Undecided, it produces two subscriptions and permanent confusion about which version is current.

Does any of this change if we are very small?

The seams matter less, because you have fewer of them, and the exit still matters exactly as much. A team of four should spend an afternoon on this rather than a fortnight, and should still run the export test and the rollout decisions before committing.