Office suites reviews: what to test before choosing

Reviews of office software are written at two moments: shortly after somebody bought it, and shortly after somebody was let down by it. The years in between, which are the years you will actually live in, are barely represented anywhere.

That is not dishonesty, it is when people feel like writing. It does mean that the body of available opinion is systematically skewed, and that the most important evidence about a suite is evidence you have to produce yourself. This page is about both: how to read what other people wrote, and what to run during a trial so you are not relying on them.

What to take away

• Published opinion clusters around the beginning and the end of a relationship. Steady state experience is the gap in every review corpus.
• A review is about a version that no longer exists and a job that is not yours. Read for recurring operational complaints, not for verdicts.
• Run the export yourself during the trial and open the result somewhere the software has never touched. This is the single most informative hour of any evaluation.
• Record what came out and what did not. That record is the only honest measure of how expensive leaving would be.

Three reasons the sample is skewed

Timing. New buyers write while everything is fresh and nothing has gone wrong yet. Departing customers write while angry. Neither describes the ordinary Tuesday that makes up almost all of your experience.

Version drift. Software in this category changes continuously. A detailed complaint from two years ago may describe something that was fixed, or something that was made worse in a way the reviewer never saw. Check the date on every review that influences you, and discount steeply.

Role mismatch. The reviewer's work is not your work. Someone who writes short documents and someone who maintains a fifteen tab financial model are reviewing different products under one name. Look for reviewers whose described work resembles yours, and ignore the rest regardless of how confidently they write.

To that add the obvious commercial point: comparison pages frequently earn a commission on sign ups, and an ordering produced that way is an ordering of commissions. It is not necessarily wrong, and it is not evidence.

What outside opinion is genuinely good for

Three things, all of them worth having:

• Recurring operational complaints. One person saying support was slow is noise. Forty people describing the same failure over two years is data, and it is the kind of data no trial will surface.
• Accounts of leaving. People who migrated away write the most useful reviews in this category, because they describe the exit, which is exactly what you cannot test in a demo and what will cost you most later.
• Candidate discovery. Finding out an option exists is a legitimate use, and the point at which outside opinion should stop influencing you.

Read for patterns and mechanisms rather than for scores. A review that says what broke and what happened next is worth fifty that say the interface is intuitive.

Run the portability audit yourself

This is the part almost nobody does, and it takes under an hour with a trial account. A fair benchmark for what the result should look like is the standard applied when a person asks for their own data: the regulator's description of data portability is about receiving information in a usable form rather than merely receiving it.

1. Put real material in. Several documents from different people, a workbook that matters, a deck, a folder structure that mirrors how you actually organize, comments from two people, and at least one document that has been revised repeatedly.
2. Share something. Internally and externally, with different permission levels, so that the export has permissions to preserve or lose.
3. Run the export an administrator can run. Not a support request. If it can only be done by asking, that is your finding, and it is a significant one.
4. Open the result on a machine that has never had the software installed. This is the step that turns an assumption into a fact.
5. Compare against the original, item by item. Use the list in the next section.
6. Write down what you found, with dates. In two years this note is the thing that tells you what leaving costs.

While you are there, ask what happens after cancellation: how long the data is retained, how long you have to retrieve it, and what is deleted immediately. Ask in writing, and keep the answer with the audit.

What usually does not come out

Check each of these specifically. Which of them survive depends on the pair of products involved, so test rather than assume.

Thing to check	Why it matters if it is missing
Folder structure and file names	An export that flattens the hierarchy is a pile, not an archive
Comments, and whether resolved threads are included	The reasoning behind a document lives in its comments
Version history	You get the current state and lose every earlier one
Sharing permissions	Restoring who could see what becomes manual work
Links between files	Models that reference other files stop calculating
Template relationships	Documents lose their connection to the template that formats them
Automation and scripts	These do not transfer between suites at all and must be rebuilt
Content held in the suite's own extras	Forms, responses, notes, and task lists are frequently outside the document export entirely
Documents owned by deleted accounts	Ask what happens to these before anyone leaves, not after

The last row deserves attention during the trial, because it is a policy question rather than a technical one and the answer differs widely. The automation questions are worth answering in the same session, since rebuilt scripts are the largest single line in any exit estimate.

When you check the formats that came out, sanity check them against a list institutions consider durable. The tables of acceptable file formats published for records transfer are a blunt, useful reference.

Ask a reference customer the right question

Vendors will supply a reference. The mistake is asking whether they are happy, which produces a happy answer.

Ask instead: what has gone wrong, and what happened next. Then follow with:

• What took longer than expected during the move?
• What did you have to rebuild by hand?
• What do you still work around?
• What did you find out after signing that you wish you had known before?
• If you were doing it again, what would you test first?

Ask for a customer of roughly your size doing roughly your kind of work. A reference ten times your size has a different product experience, because they have a named contact and you will have a queue. The operator assessment makes the same point about support, and it applies here without modification.

Common questions

Is any published comparison worth reading?

For learning the vocabulary of the category and for finding candidates, yes. For deciding, no. The author cannot know your document classes, your external constraints, or what you already run, and those three decide the answer. Work through the fit classification instead.

Should we trust the vendor's own case studies?

As descriptions of what is possible, yes. As evidence of what is typical, no. They are selected, and the selection is the entire point of them.

What if the trial goes perfectly?

Then you have learned that the product works on a small amount of new material, which is the easiest test it will ever face. Load a real volume, involve people who are not enthusiastic, and check the export. A trial with no findings usually means the trial was too gentle, not that the product is flawless.

How long should a trial run?

Long enough to include a real deadline. Software behaves differently when someone is finishing something at five o'clock, and that is the condition you are actually buying for. Two weeks that contain a genuine piece of work beat a month of exploration, and the rollout decisions are best made during that window rather than after it.